Názory k článku Kontinuální integrace: lék na lidské chyby v deploymentu

Já tedy continuous integration vnimam trochu jinak, nezapocitavam to doho nic co se deje na stroji kazdeho vyvojare, to imho neni integrace. Naopak sila continuous integration je v moznosti vybudovat automatickou pipeline, neco jako jako pasovou vyrobu v tovarne. Napr jednou denne/tydne se jenkinsem stahnout zdrojaky, zbuildi, pusti se testy, nastroje na analyzu kodu, jako sonar, fortify.. a pripadne se aplikace automaticky nasadi na staging environment kde se pusti integracni testy které simuluji realny beh popr integraci s ostatními aplikacemi. Poslednim krokem muze byt deploy na produkci, upload do uloziste/ archivu nebo neco podobneho. Takovychto pipeline se da pripravit nekolik a nektere poustet automaticky a jine rucne podle potreby.

presne takto to chapu (a pouzivame)
v clanku je sice popsany proces, ale ta podstata jaksi se vytratila.
ale zas pro nekoho, nepolibeneho CI, to je pekne cteni
:)

Kontinuální integrace by měla být kontinuální. Každá změna okamžitě vyvolá alespoň zběžné testování. Smyslem je, aby se do mainline (master branche) nedostala změna, která zablokuje vývoj; typicky branche, které nejdou zkompilovat nebo hned po startu padají, tak mají blokovaný merge, dokud to vývojář neopraví. Noční/týdenní buildy pak slouží pro detailnější testování.

Přečetl jsem si název a několik prvních slov perexu a hned jsem musel vypnout počítač a zavřít dveře. Tohle by by mělo být trestné!

Ja som mal tiez to nutkanie na zaciatku. Rozvlacny akademicko-manazersko-firemny styl pisania. Neocakaval som takyto styl na roote.

Zajímavé téma byť k článku mam výhrady.

Je tam dost vaty odvádějící od podstaty. Je popisován celý vývojový proces nějakého specifického SW, včetně věcí s CI nesouvisejících.

Ahoj, k čemu konkrétně máš výhrady? Respektive - co ti tam chybí?

Třeba jaké výhody přináší používání zmíněných nástrojů proti plánovači úloh a baťákům, popř. cronu a bashscriptům.

Ty nástroje umí rovnou generovat tickety, tagovat či mergovat verze, kde testy prošly, a třeba i bisect (najít, který konkrétní commit to rozbil a kdo je za to odpovědný) či nasazení do produkce.

Asi bych se držel krátké formy:

Pokud pracujete na větším systému (například ERP systém), tak je běžné, že k sestavení celého programu jsou potřeba značné zdroje a dlouhý čas. Běžná praxe pak je, že programátor pracuje jen na nějaké části, kterou si upravuje, kompiluje a testuje. Kontinuální integrace pak není nic jiného, než automatizovaný systém, který v nadefinovaném čase (např. každou půlnoc) provede kompilaci celého systému z aktuálních zdrojových kódů. Výsledný program může i někam nainstalovat, spustit nějakou sadu testů atd.

Důležité je, že je to jen (relativně) nový název pro něco, co se běžně dělalo už od počátku používání systémů pro správu zdrojových kódů. Script, který stáhne komplet zdrojové kódy a program komplet přeloží, byl prakticky standardem. Moderní CI se pak zaměřuje na snadnější konfiguraci (než je přepisovaní shell scriptů) a návazné funkce jako je spuštění testů apod. Nic, co by nešlo napsat jako script a spouštět přes cron, jen je to mnohem jednodušší na udržování. Některé programy to umí i "naklikat", takže nepotřebujete odborníka na bash.

Akorát by mě zajímalo, co znamená "poznámka autora". Je snad článek překladem z nějakého originálu? Já "poznámka autora" znám jen z citací, ale tady se vyskytuje i v částech, které se jako citát netváří.

Ono asi to zavisi od zlozitosti projektu, myslim teraz celkove zostavenia, pre mensie casti to moze fungovat ako CI.

Vůbec. Na složitosti projektu nezáleží, jjenom na tom, jaký je build a release proces. Takže jak podotkl @Nekola, tak pokud se občas stane, že týden na projektu nikdo nedělá a nebo dělá, ale zákazník si přeje nasazovat jenom v noci aby se mu neměnily v pracovní době věci pod rukama, tak si laskavě nepojmenovávej servery s koncovkou CI a to slovo laskavě nepoužívej ;-)

Mozna kdyz existuje nejaky termin a nekdo chce pojmenovat neco jineho, tak by si mohl vymyslet termin novy: https://en.wikipedia.org/wiki/Continuous_integration

To jestli se build pousti jednou nebo víckrát denne mě přijde už jako slovíčkaření - hlavní bod z té wikipedie vidím jako:

Constant availability of a "current" build for testing, demo, or release purposes

Plus CI zamezuje chybám typu "it works on my machine"

Několikrát tu padlo co je moderní přístup ke continuous integration a nikdo nezmínil continuous deployment. Tzn že se v rámci posledního kroku automaticky nasadi vysledny build pro malé procento uživatelů a pokud je vše ok, tak pro všechny...

Jasně, vždyť je to i v tom odkazu:

https://en.wikipedia.org/wiki/Continuous_integration

"....although he did not advocate integrating several times a day"

A jaký je rozdíl mezi continuous deployment a continuous delivery? (na wikipedii jsem koukal)

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ů . . . .