Отговори на тема  [ 12 мнения ] 
Mount-ване на папки между две виндоуски машини в скрипт 
Автор Съобщение
Ранг: Форумен бог
Ранг: Форумен бог

Регистриран на: Пон Мар 13, 2006 12:59 pm
Мнения: 3855
Местоположение: Габрово
Мнение Mount-ване на папки между две виндоуски машини в скрипт
Ще започна с по-конкретно дефиниране на заданието което гоня за повече яснота:
- на svn/git има съществуващ (текущ) проект/проекти със сорсове
- към този проект да се добавят конфигурации, скриптове и описания в поносим размер (по-малък от сорсовете и по-малък от тулчейн примерно gcc), които да не изисква инсталиране на други неща, т.е. да са portable и чекаута да стига за да тръгнат върху редово виндус пц (10-ка), която вече наричаме thin client...
- след чекаута да има "build.bat/build.sh" който да може да билдне всяка конфигурация на проекта и да остава работещо exe или библиотека или елф на редовото клиентско PC

Значи, имаме две виндоус машини - едната да я наречем клиент (thin clietn), другата сървър (build server). Сървърът има разни тулчейни и освен това има docker daemon, към който отдалечено (порт 2375) могат да се закача docker cli (клиент).
На клиентската машина има проект - сорс на C/C++ със съотвените билд описания - да кажем makefilе-ове. Гоним цел да имаме скрипт или таргет в мейкфайла чрез който да се стартира отдалечено билдване в контейнер на сървъра.
Докерът си има почти всичко - cli-то му е статично линкнато exe и слагането му на клиентската машина е достатъчно за да имаме арсеналът му. Това cli може да бъде инструктирано да праща команди към отдалечен демон, т.е. онзи порт 2375 на сървъра (там върви докер демон).
Остава една дреболия - съдържанието на проектната папка трябва да стигне до в контейнера дето тича на сървъра. Самият демон (сървърът) се оправя с това стига папката с проекта да му е достъпна като файлов достъп (open, read, write). Вариантите това да стане са:
- проектната папка се копира/синхронизира между клиента и сървъра - дали просто копиране или инкрементално е въпрос на оптимизиция; тъй като билда ще остави резулата (exe-то примерно) в същата тази копирана папка, т.е. трябва да се копира обратно пак (цялата или само новите неща - артифактите от билда)
- проектната папка да се закачи като шерната - да се сподели от клиента, примерно SMB, и да се mount-не после преди пускането на контейнера - така за докер демона ситуацията изглежда почти като локална папка
- проектната папка да не се mount-ва преди пускане на докер контейнера, да се направи после като първа стъпка вътре във вървящия контейнер - тогава отпада изискването папката да изглежда като локална
- проектната папка да е на споделено място - файл сървър, който вече е конфигуриран като network share и да е достъпен за клиента и сървъра - това в момента е паралелна нишка, но и за нея има изисквания към инфраструктура, администриране и най-вече процес на работа (програмистите ще трябва да редактират на своя мрежова работна папка - това си има и доста предимства откъм сигурност и бекъп и т.н.)
Простото копиране е кофти заради времетраенето си - няколко стотин мегабайта ако се копират преди всеки билд ще е затормозяващо - затова тоя вариант остава ако нищо друго не изскочи. Ефективно синхронизиране на разлики ще е добра посока ако се стигне до този вариант.
За да сработи втория вариант е необходимо да има работеща отдалечена файлова система - например windows share през SMB - това е трудно за менажиране понеже има изисквания към права на потребители, акаунти и тем подобни. А целта е след чекаут на нова машина да имаме работещ билд процес - без инсталиране на каквито и било инструменти (т.е. развойните машини стават thin client).
Вътре е докер контейнера да се прави копиране/маунтване/синхронизиране има повече свобода и натам копая в момента - там може да се ползва произволен механизъм който да осигури достъп до файлове за компилатора. За момента не се сещам за много опции, ама пак е посока.

Та това което търся е да мога автоматизирано (от скриптове - един в мейкфайла на клиента и един в докер контейнера) да мога да направя връзката през папка, т.е.:
- скрипта в мейкфайла подготвя и включва споделянето на текущата папка - става с "net set ..." от cmd/powershell - това работи безпроблемно но е малка част от задачата
- след като папката е шерната скрипта вика докер cli с подготвен команден ред, които да се изпълни на сървъра/в контейнера - този програмен ред съдържа командите или поне информация как да се достъпи току що споделената папка - да кажем адрес/име на компютъра, път и т.н.
- когато затича скрипта на сървъра той трябва да се закачи към споделената папка за да я направи достъпна локално, след което да пусне make или каквото там има да работи в тази папка (на сървъра - в контейнера).

От стандартните виндоуски шер-ове не се получава заради защитите - анонимен достъп не работи по дифоулт, guest трябва да се актива, че и даже да се направи нов user в guest групата за може да се закача, и т.н.
Затова погледнах алтернативи:
- други имплементации на SMB протокола, т.е. странични инструменти - SMB сървър и клиент, с които да заобиколя политиките на виндоуса - не намерих нищо смислено освен споменаване че самба-та спряла да работи на виндоус от някакво време насам
- други протоколи, с които да получа подобие на mount под виндоус - има някакви за ssh - sshfs, има за ftp нещо - трябват ми двете страни - клиент който да може да закачи протокола като виртуален нод във виндулса, както и сървър който да ги шери - за ssh, ftp, http има достатъчно сървъри и това не е толкова проблем, но клиент който да прави mount работещ не намериш; има едно руско инструментче с което се появява драйв във виндоуса със съдържанието на отдалечен ftp сървър, но докера го заплю и не се нави да хапва оттам данните
- евентуално NFS - ама там за виндоус голям батак също и не намерих нищо, което да ми позволи програмно (скриптово) да направе двете страни


Като принципна алтернатива може да се мисли за Power shell remoting - това не решава въпросът със синхронизирането/копирането, но може да алтернатива за изпълнение на някой стъпки.


Пон Апр 01, 2019 7:50 pm
Профил
Ранг: Ориентиран
Ранг: Ориентиран

Регистриран на: Сря Май 11, 2011 8:18 am
Мнения: 290
Мнение Re: Mount-ване на папки между две виндоуски машини в скрипт
Домейн контролер ще ти спести бакиите по guest-ове, права и прочие.
Какво против мрежовото съхранение на данните? Дори и на машината, която ще build-ва? Всичко ще е на нея, локално.
Другото, което се сещам - направо отдалечен достъп (terminal server) и всичко се случва на сървъра. Тогава наистина какъв да е thin клиент ще свърши работа, освен ако няма нужда от специфичен локален хардуер да се пренасочва към отдалечената сесия.


Сря Апр 03, 2019 10:48 am
Профил
Ранг: Форумен бог
Ранг: Форумен бог

Регистриран на: Вто Окт 11, 2011 10:53 pm
Мнения: 4174
Местоположение: Brussels / Пловдив
Мнение Re: Mount-ване на папки между две виндоуски машини в скрипт
Според мен трудностите идват поради нещо грешно в заданието. Ако целта е да се направи automated continuous distributed build server има варианти колкото искаш като някои обхващат целият процес на производство и дистрибутиране на софтуер, фирмуер и т.н.

Примерно ако на тези тхин клиенти не е практично да се компилита защото са твърде бавни за сложността на проекта и затова се налага да се компилира на някакъв сървър може да се ползва нещо от рода на distcc.
Ако пък целта е да се автоматизира компилиране, тестване и деплойване тогава има решения от рода на jenkins и т.н. които си работят на сървъра и се стартират автоматично след всяка промяна в сорсовете.

Т.е. така описано питането е много трудно за конкретен отговор и може би ако се тръгне от причината за тази сложнотия може да се предложи разумно и лесно решение.

_________________
Мразя да мразя ...


Сря Апр 03, 2019 12:29 pm
Профил
Ранг: Форумен бог
Ранг: Форумен бог

Регистриран на: Пон Мар 13, 2006 12:59 pm
Мнения: 3855
Местоположение: Габрово
Мнение Re: Mount-ване на папки между две виндоуски машини в скрипт
:) , хванахте ме - ще трябва да обяснявам.
Значи проблемите идват точно от това че изграждаме CI - в момента ползваме Jenkins. С две думи, покрай дженкинса има докер имиджи за различните платформи, за които билваме - няколко ембедед (арм и не само), няколко линукс (няколко арм-а, два x86 и PC/mingw). В момента виноуските са на физически slave nodes, понеже женкинса се лигави и не бръсне виндоус хост за докер (набива му "nohup" докато го пуска и 10-ката е в небрано лозе).
Наличните докер имиджи (по-точно Dockerfile-ове за някой, и локално registry за други) са вече удобен environment, в смисъла че са изградени и гарантират репродуцируем билд.
Онези thin client-и са "тънки" не като хардуер (i7+), а като натруфеност с инструментариум. Централните неща вървят на някаква виртуализация некъде из сървърното, та и те не са бавни, но не са и по-бързи от машините по бюрата. Проблемите идват от това че понякога се поддаваме на изкушението да пратим за тестване elf/exe дето е билднато локално и няма проследимост какво е точно. Особено mingw често се оказва че някой нов колега си сложиш собствена версия и разбутал локално проекта да я ползва, и после генерираното от него няма нищо общо с билда от сървърите.
Понеже доста ползваме еклипс първо тествах поддържката на билдване под докер от самия еклипс - в новите CDT-а това го има в настройките на компилатора. След доста борба тръгна в контейнерите, но се оказва че има нещо недомислено точно с пращането на файловете от хоста в контейнера. Не намерих решение и затова тествам описания в топика подход.

Всъщност темата е интересна и ще интересно да се обмени опит - явно има колеги с опит.
В момента тоя женкинс ми е трън в очите - преди време са взели решение на друго ниво да го пробваме, и са почнали да трупат код (проекти) в него. Аз наскоро се включих, но вече бях погледнал настрани - към TeamCity на Jetbrains. Та имах някаква визия какви pattern-и трябва да се гонят, и знаех с каква лекота се правят там. Като се сблъсках с женкинс беше като в товарен влак - на всяка стъпка мъка, повтаряне, ровене за плъгини, настъпване на мотики (issue-та в jira-та им) и пак в първи клас. Отделно цялото това в контекста че вече са "похарчени" няколко десетки човекомесеца работа без особен резултат (в смисъл работа в стила "копирай еди кой си проект и си почвай оттам"). Никаква визия за provisioning на environment-а - "има еди кой си компютър, там пускаме за stm32, а на еди кой си за .... Не можеш да пуснеш паралелно проекти за стм и виндоус, нищо че се билдват на различни физически машини, понеже има някъде една споделена папка и някви скриптове може да се презапишат щото са с еднакви имена ... 8O "
Преборих се да ползваме малко по-структурирани неща - "pipeline" проекти вместо досегашния хаос от "freestyle" с къстъм питон и какво ли още не вътре.
Като споменах че рАзумните хора закачат проектите на тригери по commit/check-in в сорс контрола и ме обявиха за "не-рАзумен" меко казано. "Че какво му е толкова трудното след като комитнеш да влезеш и да си стартираш билда?" 8O
Въоръжен с търпение подкопавам основите на това разбиране и се радвам че всички вече разбират поне тази част от CI. Аз пак си рева за тиймсити-то - имам още някой коз в ръкава, но ги пазя за момента в който повече хора ще се сблъскат с проблемите на женкинса и ще оценят изчадието на jetbrains.
Мамка му, 300 долара са на година, да го ... От джоба си ще ги плащам ако е толкова проблем, ама нейсе. И това ако има повече от 100 билд конфигурации (а сигурно може и 5 сървъра с по 100 да се пуснат - реално имаме достатъчно независими продуктови линии които да могат да се пръснат по различни сървъри).

Сега преглеждайки пак мнението на Палавров да допълня - venkins уж може да тръгва по комит - само че ние ползваме svn, който на всичко отгоре е оттатък жицата през vpn на 2000км. Мале, колко е бавно това - Polling през няколко минути, и това като го пуснеш на няколко десетки проекта - добре че оттатък админите са леко мързеливи и не проверяват. Има и хук-ове на сървъра, ама пак опира до тия админи, които казах ли че са мързеливи?
TeamCity-то имат хитра стратегия за лека проверка на репозиторитата, отделно имат един слой отпред който се опитва да оптимизира работата като познава ако няколко проекта ползва едно и също репозитори. Отделно диваците имат fallback стратегия ако им пуснеш hook-ове - не премахват изцяло полинг-а, а прогресивно го забавят ако преценят че hook-овете работят. Т.е. ако има hook и той се обади полинг-а се разрежда. Ако обаче полинг хване промяна, която не е известена от уж закачен hook, им светва лампичката и взимат мерки - hook-а се обявява за съмнителен и пак се сгъстяват полинг-ите, докато hook-а докаже че работи отново добре. Хитри са, или по-точно не претупват нещата.

Друга екстра, която ми напълни душата, е т.нар. private builds. Реално това е което сега се опитвам да направя, оттам тръгна цялото търсене. Тия private build-ове са начин да "пуснеш" кода от работното ти копие през build chain-на на сървъра, но без да комит-ваш. Има промяна, която е съмнителна и те е страх да комитнеш за не счупиш нещо. Искаш да я провериш през веригата на билда обаче, защото там има закачени тестове и т.н. За да ти е лесно ония гадни животни дето искат 300 на година, са измислили тия private build - съдържанието на работното ти копие се доставя по отделен канал до билд сървъра, изпълнява се с гриф "строго секретно", връща ти се резулат, а лога на svn/git и в билд лога няма нищо :wink: Пак да ги похваля колко ги бива - като пускаш private build-а има опция да му кажеш "ако мине успешно направо го commit-вай от мое име ..." 8O

Друга дреболийка - като накачулиш няколко стъпки (nested) и оня ми ти с всичкото си нахалство прерова навътре другите задачи и автоматично ти изкарва (наследява) в горния проект параметрите на долните. Няма смисъл да казвам че цялото предаване надолу става автоматично, и че женкинс това го може, ама друг път :)

Много здраво работи и с докер - направих тестов проект и съм закачил един проект от github. След малко гледам тоя го билднал и ми изкарал библиотеката. Пуля се, дзверя се - и виждам - оня като захапах github-а видял докерфайл, нагласил си билда, намерил че имало инсталиран докер демон на PC-то ми и ми билднат библиотеката... :o

Май се увлякох да описвам ентусиазма от туй пусто TeamCity - ама ме радва животното. Има още доста глезотии, които съм намерил, но ще пиша ако някой има интерес.
Вкъщи си го ползвам и като имам свободно време си играя проекти от последните 20+ години да ги подкарам на него (нелегално ползвам и лаптопа на жената за build agent че има голям диск :oops: ).

Ако някой има интерес може да погледне публичния им сървър, макар че както казах до 100 билд конфигурации е безплатен, и другото е че още от setup-а им се вижда качеството на продукта - заслужава си час-два тест.
Тоя публичния сървър е тук:
https://teamcity.jetbrains.com/
Понеже са само 802 проекта там ето един конкретен за начало - това е betaflight софтуера за квадрокоптери за stm32 и PC приложението му:
https://teamcity.jetbrains.com/project.html?projectId=OpenSourceProjects_Betaflight

А пък и един "package manager for c/c++" съм харесал, но чакам подходящ момент да го зачекна:
https://conan.io/
Не е просто имитация на apt/dpkg и подобните, много силно е насочен към c/c++ cross платформен развой. Правят го един бразилци дето правят и Jfrog, Bintray, Artifactory и други известни продукти. Реално е добра билд система в традициите на gradle примерно, но силна за c/c++ и подобни компилирани езици.

Edit: който може да изтърпи акцента на тоя бразилец ще намери за увлекателни видеотата тук:
https://docs.conan.io/en/latest/videos.html
Зачекват силно злободневни проблеми, които дори да не се ползва техния тул са полезни кат know how и стратегии. Например как избират коя паралелна верига да изпълнят първо - а именно тази с най-висок риск на гръмне "fail first".


Сря Апр 03, 2019 9:38 pm
Профил
Ранг: Форумен бог
Ранг: Форумен бог

Регистриран на: Пон Мар 13, 2006 12:59 pm
Мнения: 3855
Местоположение: Габрово
Мнение Re: Mount-ване на папки между две виндоуски машини в скрипт
jofcho написа:
Домейн контролер ще ти спести бакиите по guest-ове, права и прочие.
Какво против мрежовото съхранение на данните? Дори и на машината, която ще build-ва? Всичко ще е на нея, локално.
Другото, което се сещам - направо отдалечен достъп (terminal server) и всичко се случва на сървъра. Тогава наистина какъв да е thin клиент ще свърши работа, освен ако няма нужда от специфичен локален хардуер да се пренасочва към отдалечената сесия.

Работните станции в офиса са в домейн - само че докер контейнерите не са и пак опира до админите да измислят как няколко десетки контейнера с виндоус вътре да работят. Може и да е възможно, но не мисля че мога да направя без админско съдействие.
Гледах openshift на redhat, които предлагат и женкинс вътре. Там бегло прочетох точка че синхронизацията на локалните и облачните папки за тия цели го правят с rsync. Ако се прави вариантът който е вътре в контейнера да се синк-ват данните след старта му това може да е добра опция.
А мрежовото хранилище мисля че го споменах в единия от вариантите - това значи програмистите да ползват работно копие на проеките си някъде на сървъра - това ще сработи и има доста екстри, но ще срещне съпротива от колегите понеже им налага да го правят така. Колкото и да е бърза мрежата (всъщност само гигабит сме на пц-тата, в сървърното почват 10Г и май нагоре напоследък - дали чух за 40Г?) пак локално NVMe SSD е по-бързо. Не че някой толкова ще му сбъркат работата няколко секунди/минути, но са аргумент, срещу които трябва да има достатъчно ответни ползи.
Специфични хардуери има, по-точно интерфейси - USB, CAN(FD), всякакви етернети и field bus-и, че ако щеш и някоя серийна връзка :oops: Те трябват за тестовете и затова си има специфични физически машини като slave nodes на женкинса.

Edit: малко офф-топик - сещам се да попитам - някой може ли да препоръча devops специалист за консултант, тук в БГ? Търсим някой да дойде на място за ден примерно, да се запознае с процесите ни и да даде акъл как да подходим към проблемите, да почерпим, да си платим и т.н.? То за обяви малко е, но тук е контекста на темата. Ако е фен на TeamCity ще има скромен паричен бонус от мен ... :lol:


Сря Апр 03, 2019 9:57 pm
Профил
Ранг: Форумен бог
Ранг: Форумен бог

Регистриран на: Пон Дек 19, 2005 11:21 am
Мнения: 1025
Мнение Re: Mount-ване на папки между две виндоуски машини в скрипт
gicho написа:
Има промяна, която е съмнителна и те е страх да комитнеш за не счупиш нещо.


Какви са тия стахове да комитнеш? Не си ли работиш в отделен бранч, където да не пречиш на никой? За някоя по-сериозна промяна да чакаш да натъкмиш всичко и накрая да направиш един мега-комит не ми се вижда добра идея.

Ние последно ползвахме едно питонско buildbot и така работеше: като види, че си отворил нов бранч или има нов пуш към съществуващ си стартира билда. Всеки може да си прави бранчове и да работи по тях и да си комитва на воля. Вече като се завърши функционалността се мърджва към мастер примерно.


Сря Апр 03, 2019 11:01 pm
Профил
Ранг: Форумен бог
Ранг: Форумен бог

Регистриран на: Вто Окт 11, 2011 10:53 pm
Мнения: 4174
Местоположение: Brussels / Пловдив
Мнение Re: Mount-ване на папки между две виндоуски машини в скрипт
И на мен ми намирисва, че не се ползват dev branch-ове - те, комбинирани с git hooks позволяват всякакви варианти за автоматизиране.
Особенно ако се ползва само git и никакъв svn. Това което ми хрумва като идея е да си има един буилд сървър който на който да има отделно git remote repo което да е достъпно от всяка машина и който иска да компилира нещо да push-ва локалният си бранч към това repo където си става компилацията и като е готова със все тестове да сигнализира на девелопора, с резултата.

_________________
Мразя да мразя ...


Чет Апр 04, 2019 11:37 am
Профил
Ранг: Форумен бог
Ранг: Форумен бог

Регистриран на: Пон Мар 13, 2006 12:59 pm
Мнения: 3855
Местоположение: Габрово
Мнение Re: Mount-ване на папки между две виндоуски машини в скрипт
Както казах ползваме SVN, не че не могат да се правят feature branch-ове, но овърхед-а на svn води до това че не се случва. Нямам власт да командвам тия процеси, а тези които имат нямат желание/разбиране да го направят. И се налага да кърпим. Понякога по определен feature работят няколко човека едновременно, съответно всеки си има работно копие на този бранч и всеки може да му се прииска да го "прокара" през билд/тест процеса.
Това с общото репозитори на билд сървъра как ще се сработи с 30-тина опитващи в един и същ момент да пуснат билд на някакъв проект, всеки с различни излияния в неговото копие?
Със сигурност по-чист процес в частта на организация на сорсове и проекти ще ни спаси от доста проблеми, с които в момента се сблъсквам. И аз предпочитам да щракнем на git и да сменим стратегията (git flow не пасва добре с svn, или поне оставя доста дупки през които небрежни девелопъри могат да обозят нещата). Но за момента не се приема с довода "че какво му е на свн? а, това ли нямал от гит? ми че аз не го ползвам така, не ми трябват тия неща...".
Какви hook-ове да сложим - нали споменах че администрирането на svn е извън нашия контрол и дори за тригери към билд сървърите не можем да ги ползваме.
А страховете да се комит-не са донякъде разбираеми - има хора с по-малко опит, има случаи в които един сорс се ползва на 20-тина различни места (продукта). Има тестове които не можеш да пуснеш на твоята машина - иска си хардуер и т.н. Понякога много помага да повториш някакъв билд/тест с лека корекция в параметри или сорса за да получиш нова информация, вместо да стегнеш куфара и да прелетиш няколко хиляди км.
Доколкото съм чел, това с "мега-комит-а" е много често явление в организациите, които ползват свн. Може би затова го приемам като едва ли не естествено, макар че строго погледнато не бива да се допуска още на първо четене.
Моята позиция е че такава "екстра" (частен, скрит билд/тест) може да е полезна на някого - не съм човекът (нито като власт, нито като разбирания) които ще отхвърли да го направи ако друг смята че му е полезно.

Темата се отплесва в приятна посока за по-генерален билд инжинеринг и ще е хубаво да не спира без развитие. Ама може би не и е тук мястото?
А по питането ми за консултант по темата има ли някакви идеи? Всеки човек с опит ще е полезен - особено хора минали през svn и запознати с предимствата на гит - може би това ще ускори миграцията при нас. За една продуктова линия има шанс да се преборя, което ще е добро начало.


Чет Апр 04, 2019 4:20 pm
Профил
Ранг: Форумен бог
Ранг: Форумен бог

Регистриран на: Сря Юли 11, 2007 9:16 am
Мнения: 1705
Мнение Re: Mount-ване на папки между две виндоуски машини в скрипт
Хубаво де, защо локално не си сложите git сървър, да създадете същите проекти каквито имате в SVN. Да си автоматизирате билд процеса с някой CI и да си се кефите. С хуук при пуш/мръдж рекуест в мастър бранча - винаги можете с няколко команди да пуснете кода към немския SVN където да става официалният билд.
Така вие локално в офиса ще сте си хепи и ония ще си получават нужните разработки по SVN.


Чет Апр 04, 2019 4:27 pm
Профил
Ранг: Форумен бог
Ранг: Форумен бог

Регистриран на: Вто Окт 11, 2011 10:53 pm
Мнения: 4174
Местоположение: Brussels / Пловдив
Мнение Re: Mount-ване на папки между две виндоуски машини в скрипт
Симбиозата между git и svn е сравнително читава - т.е. локално всички си ползвате гит пък за официалният свн си прехвърляте когато е готово. Но при това положение наистина ще трябва да направите паралелна буилд система и т.н.

А не е задължително да се build-ват само master може спокойно и всеки commit към feature branches да се пуска за build & test и той да си рапортува резултата.

Но честно казано досега не ми се е налагало да разчитам на репорт след автоматизирано тестване да ми лови бъговете - винаги гледам да издам максимално изтестван и качествен код така, че да не се налга после да се чака за поправка. Така итерациите ми на писане, компилиране, тестване са максимално кратки. То подозирам, че при вас точно от тук идва болежката, че точно тези итерации стават изнервящо бавно. Т.е. проблемът ви е доста по надълбоко на чисто архитектурно ниво - не говоря за архитектура на самия продукт а за архитектурата на сорсовете и процесите за разработка. Ако там е забатачено и изпуснато да се оправи с времето ще е мъка отвсякъде да се оправи и не знам дали има някой който да се навие да го оправи без има свобода да кастри с брадвата докато и да гради на чисто след това. И то този процес ще отнеме време през което едва ли имате как да не пипате сорса ... мъка си е.

_________________
Мразя да мразя ...


Чет Апр 04, 2019 5:50 pm
Профил
Ранг: Форумен бог
Ранг: Форумен бог

Регистриран на: Пон Мар 13, 2006 12:59 pm
Мнения: 3855
Местоположение: Габрово
Мнение Re: Mount-ване на папки между две виндоуски машини в скрипт
Да, едното което имам като идея е да се мигрира локално към гит, в началото за някой по-самостоятелни проекти. Но за момента дори споменаването че ще работя по гит води до мръщене. Пускам по някой "teaser" да захапят, но предполагам инерцията да се кара както си знаят ще е основната съпротивителна сила - на никой не му се учат нови неща, особено когато си мислят че текущото няма кусури.
Да, билдването няма да е само на мастър, целта е общо взето всичко бранчове да се билдват и да има история на процеса. Затова и всичко се тригерира по комит на кода (било то в мастър, било в девелоп или feature branch - всичко това условно поради липсата на строга организация).
А това да се комит-ва само проверен код е тънката част - в общия случай си прав, но това е само когато имаш шанс да си пуснеш тестовете при теб след всеки билд. Тук идват две особености:
- първо дали тестовете изобщо могат да тръгнат при теб - понякога (доста често) хардуера още го мислят, или го има само в немско примерно;
- като кажеш "да си проверя нещата" не знам дали говориш за нашата постановка - при нас си има отдел за тестване, който прави паралелно тестовете по същите requirements по които ние пишем кода; т.е. на девелопър не му е работа (не му се плаща) да прави тестове (оня прословут V-модел). Като казвам "прави тестовете" не значи да стои в терминал и вика "make test", говоря за процеса при който се разработват тестове. В общия случай някой от тестовите инжинери получава документацията и прави тест (да каже някакъв питонски скрипт). После го качва някъде и той или някой друг "закача" този тест към един или повече "софтуерни продукта". Т.е. ако аз съм правил някакъв сорс изобщо никой не е длъжен да ми достави теста на мен - както казах те си имат системи на които пускат тестовете (фикстури - стендове). Аз качвам кода и получвам обратно "работи" или "не работи", разбира се с подробно описание какви case-ове и по кои requirements са минали ок или са гръмнали.
Както го пиша предполагам се разбира че говорим основно за интеграционното тестване - отделно първото ниво unit test са си грижа на разработчика и той може да разчита на нещата, които са покрити там, или на друг колега с когото обаче работят в гъста кооперация.
Поради естеството на системите ни големите проблеми идват при интегриране на тия сорсове в различни (разнообразни) проекти. Първото ниво на проблеми са че нещо се е билдвало в един проект, но някъде този сорс се използва от друг проект, който обаче ползва друго обкръжение - дали компилатор, дали рънтайм, дали размер на стек, дали версия на кърнел, дали ...
Първото което съм си поставил за цел (стъпка по стъпка) е да хвана своевременно всичките зависимости и когато commit-на един ред в някакъв мижав хедър спокоен че съм билднал при мен проекта и всичко работи, да бъда изненадан от нотификации че в 3-4 други проекта билда се е издънил от моя commit. Съответно да си обмисля промените дали са ок, ако трябва да говоря със "засегнатите", да се планира работа по интегриране на новата ми версия там.
Като цяло тези автоматизирани билд/тест системи нали са за да улеснят процеса - той самият трябва да си е правилен като workflow, но от инструментариума който го движи се очаква да може да поеме всички нужди без да се стига до ръчни стъпки. Независимо дали билдвам feature или master или develop си мисля че може да полезно да преизползвам нагруханите там описания на environment, на стъпки, на тестове и така нататък за проба преди истински commit. Няма много смисъл от 15 версии в които се повтаря "оправям синтаксиса щото не познавам езика на който пиша и все бърка апостроф със кавички и забравям ";" накрая на реда, а и понякога забравя да escape-вам специални символи в низове, а един път вместо "test" написах "tset".
Нека хвърли камък който не е правил и commit-вал такива грешки ...? В гит могат да се трият/забатачват "версии", в svn не може - всичко си стои там. И после проект от няколко C файла почва да заема 800+мб на диска. Като търсиш назад ти се пречкат тия 15 версии - в тях няма техническо съдържание, има история на грешките. Когато не можеш локално да пуснеш нещо (щото нямах хардуера примерно) няма как да провериш дали работи.

В интерес на истината тук не малка част от нагласата ми че "такова нещо трябва" идва точно от наличието му в teamcity-то - логиката ми е че щом са се потили да го направят явно са видели смисъл. Е, не изключвам някой отнесен като мен да го е поискал, но това е по-типично за женкинса. При teamcity нещата следват обмислена идеология, а не 1000+ плъгина със свободни съчинения на всички желаещи.
В женкинс има нещо подобно, ама не точно - на проекти които са от тип "pipeline" или "multibranch pipeline" на всеки стар билд има копче "replay" - тогава ти показва описанието на проекта (стъпките, обкръжение, параметри) както са били в точно избрания от теб билд номер. И може да сменим временно (без да се променя проекта или нещо да се комитва) и да пуснеш. Примерно чудиш се на тоя sed дали не си сбъркал израза и искаш да пробваш с нещо различно - пускаш replay на билд номер #555 и сменяш, пускаш и виждаш резултат.


Чет Апр 04, 2019 8:38 pm
Профил
Ранг: Форумен бог
Ранг: Форумен бог

Регистриран на: Вто Окт 11, 2011 10:53 pm
Мнения: 4174
Местоположение: Brussels / Пловдив
Мнение Re: Mount-ване на папки между две виндоуски машини в скрипт
Тя тая тема е за бира, ама ...

Значи точно това което описваш като дев процес мен лично много ми е криво да го следвам. То явно естеството на работата ви е такова и няма измъкване. По конкретно - времето което отнема итерацията "писане ... тестване" трябва да минимално за да може да не се губи време за припомняне кое как беше. От моята камбанария това оскъпява излишно цялата разработка и го избягвам като дявол тамян т.е. целият дев процес си го проектирам така, че да всичко да е модулно, независимо. Това да не мога да тествам сам на момента на желязото направо би ме отказало да пиша. Един колега си пишеше симулатори за да си тества нещата като работеше дистанционно с нас но нещо не ме грабна този начин на работа. Друг начин по който съм го заобикалял този проблем е самият проект да го стартирам локално на дев машината ми като го залъгвам с данни колкото да си го изтествам, че е ок. Разбира се после се тества от други хора но избягвам да разчитам друг да ми търси бъговете т.е. съзнателно да не си тествам сам защото друг ще тества след мен.

Прави ми впечатление, че не споменавяш за код ревюта - това си е почти задължително нещо - проверяващият хем може да види някой очевиден проблем, хем по този начин се дублира познаването на кода, повишава се качеството и т.н.

Оносно ползването на свн и гит - свн от години излиза от употреба и се заменя основно с гит, то гит дефакто вече е стандарт и отдавна поне на мен не ми се налагало да работя с нещо друго. Имаше едно две неща които ми липсваха/бахя по добре направени но се свиква. За мен вече е блокиращо изискване - няма ли гит и мен ме няма. Не знам тези твои колеги които се противят дали са се замисляли ако се наложи да си сменят работата и се налага да знаят гит за каквато и да е нова как ще са неконкуретни. Знам, скъпо е, но е по скъпо да останеш в миналото докато светът покрай теб е отишъл някъде другаде.

Хубава практика е при всеки буилд да се вкарва SHA1 на комита като дефинирана константа от командния ред на компилатора или пък като някакъв хедър файл. Също да се блокира буилда ако има някакви некомитнати промени. Така се създават хубави работни навици.

Не съм ползвал досега teamcity но като гледам как ти е харесало няма причина да не го ползваш, напротив.

Може би наистина първата стъпка за справянето на този проблем е да изолираш всичкия код който се ползва в повече от един продукт в отделен модул. git submobules е доста добър начин да се управляват такива проекти и да не се чупят други проекти след всяка промяна - т.е. всички проекти които ползват даден подмодул си знаят кой точно комит да ползват и колкото и промени да правиш в подмодула докато никой не го е ъпдейтнал в друг проект няма и проблем. А когато някой го ъпдейтне си има грижата да отрази направените промени т.е. така в един нов комит имаш ъпгрейд на подмодул със съответните промени които е изисквало това - така всичко си идва на мястото.

Та този процес си е на практика рефакторинг и ако го правиш на малки стъпки би трябвало да мине гладко и безболезнено и да няма съпротива.

_________________
Мразя да мразя ...


Чет Апр 04, 2019 10:11 pm
Профил
Покажи мненията от миналия:  Сортирай по  
Отговори на тема   [ 12 мнения ] 

Кой е на линия

Потребители разглеждащи този форум: 0 регистрирани и 3 госта


Вие не можете да пускате нови теми
Вие не можете да отговаряте на теми
Вие не можете да променяте собственото си мнение
Вие не можете да изтривате собствените си мнения
Вие не можете да прикачвате файл

Търсене:
Иди на:  
cron
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group.
Designed by ST Software for PTF.
Хостинг и Домейни