POKUD NA TO MUSÍ NĚKDO MYSLET A VĚNOVAT TOMU 1 a více sekund je to ŠPATNÉ(NEVHODNÉ) ŘEŠENÍ.
Jejich postupy mohou být třeba vhodnější(efektivnější) pro jejich způsob práce.
Dosud se celá debata odvíjela celkem správným směrem, ale výše citovaný příspěvěk jako celek je podle mě agresivní útok hlupáka. Nejde pro jeden dílčí krok zahodit přínos celé pipeline. Udělat commit v gitu, zvlášť aby k něčemu byl dá určitě víc práce, než na složce se zdrojáky udělat alt+f5 a odzálohovat to někam na server. Git workflow je třeba se trochu naučit, nedělat commit 1x za měsíc, ale ideálně vždy po uzavření nějaké nové/upravené funkcionality, případně i v mezikrocích ("WIP: ..."). To je ta práce navíc. Na druhou stranu to ale lidem může ušetřit spoustu času. Proč se dělala tahle změna? git blame, git log, git diff - aha, proto. A není potřeba se někde prohrabovat zip souborama na sdíleném disku ve firmě a hledat, kdy se tam tohle vlastně dostalo, pokud to vůbec někde je.
Vysvětlit přínos téhle práce navíc jednak vedení a jednak těm vývojářům může být náročný úkol, ale je potřeba argumentovat právě případy, kdy kvůli nějakému pochybení v deploy procesu to ty lidi/majitele stojí násobně víc času. Takhle potom jde třeba odpovědět - nevím, teď nemám čas ti to hledat, najdi si to v gitu a mám klid na další práci.
Z vlastní zkušenost znám případ, kdy majitel firmy vzal notebook nemocného zaměstnance a vezl mu ho domů, aby se dostali k aktuálním zdrojákům a překladu.
Jiná (odstrašující) zkušenost: Zaměstnanec v pracovní době vytvoří něco, co bere jako svoje know-how a nechce ho předat dál. Jakkoliv strastiplnou cestu musel projít a mentální úsilí vyvinout, pořád je to práce zaměstnance pro zaměstnavatele a tak by s tím mělo být nakládáno.
Vztaženo na původní dotaz za mě takto:
Krok jedna - všechny zdrojáky musí do repozitáře, bez debaty, klidně befelem. V první fázi tak jak jsou, klidně i s různými balasty typu vcproj.sln, .cproject a podobně. V tomhle by měl mít tazatel podporu vedení, je to práce zaměstnanců firmy v pracovní době, tedy majetek zaměstnavatele a zaměstnavatel by k tomu měl mít přístup. Částečně se tím eliminuje bus faktor.
Krok jedna a půl - vysvětlit základní git workflow. Návod velkým písmem na A5 max, na to klíčové to stačí. Musí tam být init, add, .gitignore, remote add, commit, reset, push, s velkým varováním commit --amend (pro situace a ještě jsem zapomněl upravit tenhle řádek v readme) s tím, že commit --amend nelze po push, pak už je třeba nový commit a případně stash. S tim si lze běžně vystačit. Podrobnější návod může být k ruce, kde bude návod na řešení dalších základních situací (branch, checkout, clone, pull, merge), ale git cook book na začátek je moc.
Krok dva - tazatel bude postupně automatizovat build systém tak, aby se buildovalo z toho, co je v repozitáři. Ideálně přes dvě větve, kdy do master větve jde jen to, co jde mergovat a zkompilovat, ale jde to i tak, že vše může být v masteru, ale pokud commit message nezačíná "WIP:" musí to jít kompilovat. Následně se nasazují jen verze, které splňují výše uvedené pravidlo, ideálně v help-u těch aplikací je uveden commit (např.
git describe --match=NeVeRmAtCh --always --dirty=M), ze kterého se to sestavilo. Tím se předejde pěti různým verzím aplikace, shodně označeným 1.2. Podmínka kompilovatelnosti zabrání tomu, že se např. v commitu zapomene na nově vyvořené soubory.
Krok tři - postupovat v automatizaci - ideálně každý problém v produkci přetavit v další test, automatizovat reportování chyb z testů zpět vývojářům, zpřísňovat parametry překladu např. -Werror atp.
Štábní kultura zdrojáků s tím sice souvisí taky, ale pokud jsou jednotlivé projektíky one-man-show, pak bych to případně tlačil až v pozdějších fázích.
Jo a nezapomenout na zálohování repozitáře!
88 Odpovědí
24189 Zhlédnutí