Vlákno názorů k článku Kontinuální integrace: lék na lidské chyby v deploymentu od mrk - Continuous Integration je neco trosicku jineho nez-li automaticky...

Continuous Integration je neco trosicku jineho nez-li automaticky build/regression testing/deployment testing.

CI by mel kdykoliv umoznit stiskem jedineho tlacitka deployment do produkce v zadouci kvalite. To vyzaduje nemit zadny branche, nybrz pouzivat "feature toggle" - rozdelane featury, ktere nejsou vhodne do produkce, musi byt umozneno vypnout jednoduchou konfiguraci deploymentu. Tak se kuprikladu delaj A/B testy v Google, FB nebo Uberu. Pak prirozene muze byt problem, kdyz se objevi bug nezachycen regresnimi, integracnimi nebo konformnimi testy. V praxi je pak vicero verzi services a klienti vedi, ktere verze muzou pouzivat (e.g. Uber ma vicero verzi pro ruzne A/B featury, pak na mobilu klienti pujdou na service, ktera jejich app verze umozni; predpoklad je, ze updates se stahnout samotny).

Naproti tomu kdyz mate feature branches, tyhle neumoznuji CI. Pak muzete mit treba vicero buildu za den, pro kazdej branch jeden, a zpoustet automaticke testy, no a do deploymentu dat kuprikladu posledni funkcni verzi (dodelanou), nebo verzi s nejmin zavaznimi selhanimi testu.

Tohle jsou drobny detaily, akorat hodne dulezity, nebot pak development vypada docela jinak - pri CI se muze commitovat primo do masteru a proste se afektovanej modul oznaci jako neprodukcni. Pri feature branches se pak musi delat merge hell a to proste zpomaluje vyvoj.

Pokud si s někým navzájem vlezeš to větví a pohrabete se v tom samém, tak se merge hell nezbavíš (přímo úměrně počtu změn!), ani kdyby jsi to vyvýjel na božích slibech a je úplně jedno, jak se ty branche jmenují a z kterého bereš věci do testingu nebo na release. A úplně stejně, pokud děláš nějakou feature a měsíc si nestáhneš změny z "mastera" (třeba mainline pro development), tak ti nepomůže ani svěcená voda. Buď si naplánuješ dobrý vnitří interface v aplikaci a podle toho začleňuješ moduly/balíčky . . . a nebo budeš dělat nedestruktivní změny. Pokud to ale nedodržíš a naplánuješ lidem práci do kříže, opět je jedno, jak se ty větve jmenují, nebo kolik svatých za tebou stojí . . .

Jo, prirozene, akorat ta strategie je proste jina, Continuous Integration je "feature toggles", normalni automatickej testing/deployment je pres "feature branches". Jestli chces delat v Silicon Valley, tak se budes drzet CI, jestli v Evrope, tak to druhy.

Prave tohle pondeli jsem probiral CI s feature toggles se sefem engineeringu Uberu v Amsterdamu, a videl jsem jeho reakce na branches, proste s tim nemuzou delat A/B testing a jejich developri (kteri musej byt hodne vysoce v hackerranku) si stezujou na pripadnou nutnost merge, tak tam resi, jak to minimalizovat nejlepsim moznym zpusobem.

Hele, každému vyhovuje něco jiného, i na projektu trochu záleží, ale co jsem se snažil říct je to, že pokud se s verzí kódu hodně časově odloučíš od mainline (proběhne hodně změn) - třeba měsíc na feature branchi, nebo hotfixy začnaš backportovat po 3 týdnech atd. tak je úplně jedno, jaký postup používáš - kód bude někde jinde a pak už je to jenom o ruční práci. Proto mám rád způsob práce jako features na samostatné celky, pak už většinou jenom stačí případně upravit nějaké 2-3-5 vstupů a je to . . . a nebo případně spoustu malých tasků a sypat to tam zrovna. Cokoliv ostatního smrdí merge-hell nezávisle na tom, čím to manageuješ - to odloučení za tebe nic automaticky nevyřeší - jedině to přehrát něcí poslední fungující verzí - to je ale taky na prd . . .

Ono CI také původně vzniklo jako metodika a doporučené postupy. Teprve časem se pro něj začaly dělat specializované programy. Ty ale samy o sobě nic neřeší. Pokud se nedodrží ty doporučené postupy (commitovat často, stahovat změny často atd.), tak si člověk nepomůže. Zkrátka, CI neřeší jak to udělat abych mohl lidem dávat práci do kříže. CI říká, že to dělat nemám.

Přesně tak. Spousta lidí si myslí, že třeba GIT za ně elegantně řeší konflikty, ale to není pravda, GIT akorát dává přesný nástroj. Zkusil bych takovou metaforu: Na co je ti skvělá a ostrá sekera, když ti někdo dá sekat dřeva plné skob a hřebíků . . . .