Pojďme diskutovat o tom, proč jsou nástroje CI a CI zcela odlišné věci.
Jakou bolest má CI řešit, kde se vzal nápad, jaká jsou nejnovější potvrzení, že to funguje, jak pochopit, že máte praxi a ne jen nainstalovaného Jenkinse.
Nápad udělat reportáž o kontinuální integraci se objevil před rokem, když jsem chodil na pohovory a hledal práci. Mluvil jsem s 10-15 společnostmi, pouze jedna z nich dokázala jasně odpovědět, co je CI, a vysvětlit, jak přišli na to, že ji nemají. Zbytek mluvil o Jenkinsovi nesrozumitelné nesmysly :) No, máme Jenkinse, staví, CI! Během reportáže se pokusím vysvětlit, co to vlastně Continuous Integration je a proč k tomu mají Jenkins a podobné nástroje velmi slabý vztah.
Takže, co se vám obvykle vybaví, když slyšíte slovo CI? Většina lidí si vybaví Jenkinse, Gitlab CI, Travise atd.
I když si to vygooglujeme, dá nám tyto nástroje.
Pokud jste obeznámeni s dotazováním, pak vám ihned po vypsání nástrojů řeknou, že CI je, když vytváříte a spouštíte testy v Pull Request pro odevzdání.
Průběžná integrace není o nástrojích, ne o sestavách s testy v oboru! Continuous Integration je praxe velmi časté integrace nového kódu a pro její použití není vůbec nutné oplotit Jenkins, GitLab atd.
Než přijdeme na to, jak plnohodnotný CI vypadá, ponořme se nejprve do kontextu lidí, kteří s ním přišli, a pociťme bolest, kterou se snažili vyřešit.
A vyřešili bolest ze spolupráce jako tým!
Podívejme se na příklady obtíží, kterým vývojáři čelí při vývoji v týmech. Zde máme projekt, hlavní větev v git a dva vývojáře.
A dali se do práce, jak byli všichni dávno zvyklí. Vzali jsme úkol ve velkém schématu věcí, vytvořili jsme větev funkcí a napsali kód.
Jeden dokončil funkci rychleji a sloučil ji do hlavní.
Druhý potřeboval více času, později se spojil a skončil konfliktem. Nyní, místo psaní funkcí, které firma potřebuje, tráví vývojář svůj čas a energii řešením konfliktů.
Čím obtížnější je zkombinovat vaši vlastnost se společnou předlohou, tím více času na ní trávíme. A ukázal jsem to na docela jednoduchém příkladu. Toto je příklad, kdy jsou vývojáři pouze 2. Představte si, že do jednoho úložiště píše 10 nebo 15 nebo 100 lidí ve firmě. Budete se zbláznit, abyste vyřešili všechny tyto konflikty.
Existuje trochu jiný případ. Máme mistra a několik vývojářů, kteří něco dělají.
Vytvořili větvičku.
Jeden zemřel, vše bylo v pořádku, úkol splnil.
Druhý vývojář mezitím odevzdal svůj úkol. Řekněme, že to poslal ke kontrole. Mnoho společností má praxi zvanou recenze. Na jednu stranu je tato praxe dobrá a užitečná, na druhou nás v mnoha směrech brzdí. Nebudeme se tím zabývat, ale zde je skvělý příklad toho, k čemu může vést špatná recenze. Odeslali jste žádost o stažení ke kontrole. Vývojář nemá co dělat. Co začne dělat? Začíná se věnovat jiným úkolům.
Během této doby udělal druhý vývojář něco jiného.
První splnil třetí úkol.
A po nějaké dlouhé době byla jeho recenze testována a on se snaží přijít na kloub. Tak o co jde? Zachycuje obrovské množství konfliktů. Proč? Protože zatímco jeho požadavek na stažení visel v recenzi, spousta věcí se již v kódu změnila.
Kromě příběhu s konflikty je tu příběh s komunikacemi. Zatímco vaše vlákno visí na kontrole, zatímco na něco čeká, zatímco pracujete na nějaké funkci po dlouhou dobu, přestanete sledovat, co se ještě mění v kódové základně vaší služby. Možná, že to, co se nyní snažíte vyřešit, bylo vyřešeno již včera a můžete použít nějakou metodu a znovu ji použít. Ale to neuvidíte, protože vždy pracujete se zastaralou větví. A tato zastaralá větev vždy vede k tomu, že musíte vyřešit konflikt sloučení.
Ukazuje se, že pokud pracujeme jako tým, tj. v úložišti se nehrabe jeden člověk, ale 5–10 lidí, pak čím déle nepřidáváme svůj kód do hlavního serveru, tím více trpíme, protože nakonec potřebujeme něco a pak to sloučit. A čím více konfliktů máme a s čím starší verzí pracujeme, tím více problémů máme.
Dělat něco společně je bolestivé! Vždy si stojíme v cestě.
Tento problém byl zaznamenán před více než 20 lety. První zmínku o praxi kontinuální integrace jsem našel v extrémním programování.
Extreme Programming je první agilní framework. Stránka se objevila v roce 96. A myšlenkou bylo využít jakési programátorské praktiky, plánování a další věci, aby byl vývoj co nejflexibilnější, abychom mohli rychle reagovat na případné změny nebo požadavky našich klientů. A s tím se začali potýkat před 24 lety, že když něco děláte hodně dlouho a okrajově, tak tomu věnujete víc času, protože máte konflikty.
Nyní budeme jednotlivě analyzovat frázi „Nepřetržitá integrace“. Pokud to přeložíme přímo, dostaneme kontinuální integraci. Ale jak je to spojité, není příliš jasné, je to velmi nespojité. Ale jak velkou integraci má, také není příliš zřejmé.
A proto vám teď dávám citáty z Extreme Programming. A obě slova rozebereme samostatně.
Integrace - Jak jsem již řekl, snažíme se o to, aby každý inženýr pracoval s nejaktuálnější verzí kódu, aby se snažil přidávat svůj kód co nejčastěji do společné větve, aby se jednalo o malé větve. Protože pokud jsou velké, můžeme se snadno na týden zaseknout s konflikty při sloučení. To platí zejména v případě, že máme dlouhý vývojový cyklus, jako je vodopád, kde vývojář odešel na měsíc, aby vystřihl nějakou obrovskou funkci. A uvízne ve fázi integrace na velmi dlouhou dobu.
Integrace je, když vezmeme svou větev a integrujeme ji s pánem, sloučíme ji. Existuje ultimátní možnost, když jsme vývojář transbase, kde se snažíme zajistit, abychom okamžitě zapisovali do mastera bez jakýchkoli dalších větví.
Obecně integrace znamená vzít váš kód a přetáhnout jej do hlavního serveru.
Co je zde míněno slovem „nepřetržitý“, čemu se říká kontinuita? Praxe znamená, že se vývojář snaží integrovat svůj kód co nejrychleji. To je jeho cílem při plnění jakéhokoli úkolu – dostat jeho kód do masteru co nejrychleji. V ideálním světě by to vývojáři dělali každých pár hodin. To znamená, že vezmete malý problém a sloučíte jej do hlavního. Všechno je skvělé. To je to, o co usilujete. A to se musí dělat průběžně. Jakmile něco uděláte, okamžitě to vložíte do mistra.
A vývojář, který něco vyrábí, je zodpovědný za to, co udělal, aby to fungovalo a nic neporušil. Zde obvykle vychází testovací příběh. Chceme provést nějaké testy našeho odevzdání, sloučení, abychom se ujistili, že to funguje. A právě tady vám Jenkins může pomoci.
Ale s příběhy: udělejme změny malé, nechme úkoly být malé, udělejme problém a okamžitě to zkusme nějak vložit do masteru – tady žádný Jenkins nepomůže. Protože Jenkins vám pomůže pouze s prováděním testů.
Můžete se bez nich obejít. Tohle ti vůbec neublíží. Protože cílem praxe je měřit co nejčastěji, abychom v budoucnu neztráceli obrovské množství času na nějaké konflikty.
Představme si, že jsme z nějakého důvodu v roce 2020 bez internetu. A pracujeme lokálně. Nemáme Jenkinse. Tohle je fajn. Stále můžete pokračovat a vytvořit místní pobočku. Napsal jsi do něj nějaký kód. Úkol jsme splnili za 3-4 hodiny. Přešli jsme na master, provedli git pull a sloučili tam naši pobočku. Připraveno. Pokud to děláte často, gratulujeme, máte průběžnou integraci!
Jaké důkazy v moderním světě existují, že stojí za to utrácet energii? Protože obecně je to těžké. Pokud se pokusíte takto pracovat, pochopíte, že některé plánování bude nyní ovlivněno, budete muset věnovat více času rozkládání úkolů. Protože když to uděláš člověče..., pak se nebudeš moci rychle dohodnout a v důsledku toho se dostaneš do problémů. Už nebudete mít praxi.
A bude to drahé. Od zítřka nebude možné okamžitě pracovat pomocí kontinuální integrace. Všem vám bude trvat velmi dlouho, než si na to zvyknete, bude vám trvat velmi dlouho, než si zvyknete na rozkládání úkolů, bude trvat velmi dlouho, než si zvyknete na předělání opakovacího cvičení, pokud ho máte . Protože naším cílem je, aby se to dnes rozpustilo. A pokud provedete kontrolu do tří dnů, pak máte problémy a kontinuální integrace pro vás nefunguje.
Ale máme teď nějaké relevantní důkazy, které nám říkají, že investice do této praxe má smysl?
První, co mě napadlo, byl State of DevOps. Tohle je studie, kterou kluci provádějí už 7 let. Nyní to dělají jako nezávislá organizace, ale pod Googlem.
A jejich studie z roku 2018 ukázala korelaci mezi společnostmi, které se snaží používat krátkodobé pobočky, které se rychle integrují, často se integrují a mají lepší ukazatele výkonu IT.
Jaké jsou tyto ukazatele? Jedná se o 4 metriky, které ve svých dotaznících berou od všech společností: frekvence nasazení, doba realizace změn, doba obnovení služby, míra selhání změn.
A za prvé, existuje tato korelace, víme, že společnosti, které často měří, mají mnohem lepší metriky. A mají rozdělení společností do několika kategorií: jsou to pomalé společnosti, které produkují něco pomalu, středně výkonné, vysoce výkonné a elitní. Elitou jsou Netflix, Amazon, které jsou super rychlé, vše dělají rychle, krásně a efektivně.
Druhý příběh, který se stal právě před měsícem. Technology Radar má skvělý článek o Gitflow. Gitflow se od všech ostatních liší tím, že jeho větve jsou dlouhověké. Existují vypouštěcí větve, které žijí dlouhou dobu, a představují větve, které také žijí dlouhou dobu. Tato praxe v Technology Radar se přesunula na HOLD. Proč? Protože lidé čelí bolesti integrace.
Pokud vaše ratolest žije velmi dlouho, zasekne se, zhnije a my začneme trávit více času snahou o nějakou změnu.
A nedávno autor Gitflow řekl, že pokud je vaším cílem nepřetržitá integrace, pokud je vaším cílem, že chcete rolovat co nejčastěji, pak je Gitflow špatný nápad. Samostatně k článku dodal, že pokud máte backend, kde o to můžete usilovat, tak je pro vás Gitflow zbytečný, protože Gitflow vás zpomalí, Gitflow vám bude dělat problémy s integrací.
To neznamená, že Gitflow je špatný a neměl by se používat. Je to pro jiné příležitosti. Například, když potřebujete podporovat několik verzí služby nebo aplikace, tedy tam, kde potřebujete podporu po dlouhou dobu.
Ale pokud budete mluvit s lidmi, kteří takové služby podporují, uslyšíte spoustu bolesti o tom, že tato verze byla 3.2, což bylo před 4 měsíci, ale tato oprava v ní nebyla zahrnuta a nyní, aby bylo možné ji vyrobit, musíte udělat spoustu změn. A teď zase uvízli a teď se týden pokoušeli implementovat nějakou novou funkci.
Jak správně poznamenal Alexander Kovalev v chatu, korelace není totéž jako příčinná souvislost. To je pravda. To znamená, že neexistuje žádná přímá souvislost, že pokud máte kontinuální integraci, všechny metriky budou skvělé. Existuje však pozitivní korelace, že pokud je jeden jeden, pak je s největší pravděpodobností i druhý. Není to fakt, ale s největší pravděpodobností. Je to jen korelace.
Zdá se, že už něco děláme, zdá se, že již splýváme, ale jak můžeme pochopit, že stále máme kontinuální integraci, že se poměrně často slučujeme?
Jez Humble je autorem příručky, Accelerate, webové stránky Continuous Delivery a knihy Continuous Delivery. Nabízí tento test:
- Kód inženýra se dostane k veliteli každý den.
- Pro každý odevzdání spustíte testy jednotek.
- Sestavení v masteru spadlo, bylo to opraveno asi za 10 minut.
Navrhuje použít takový test, abyste se ujistili, že máte dostatek praxe.
To poslední považuji za trochu kontroverzní. To znamená, že pokud to můžete opravit za 10 minut, pak máte kontinuální integraci, zní to podle mého názoru trochu divně, ale dává to smysl. Proč? Protože pokud často mrznete, znamená to, že vaše změny jsou malé. Pokud malá změna znamená, že vaše hlavní sestavení je nefunkční, můžete rychle najít příklad, protože změna je malá. Zde jste měli malé sloučení, změnilo se v něm 20-30 řádků. A podle toho můžete rychle pochopit, jaký byl důvod, protože změny jsou malé, máte velmi malou oblast pro hledání problému.
A i když se náš produkt po vydání rozpadne, pak pokud máme praxi kontinuální integrace, je pro nás mnohem jednodušší jednat, protože změny jsou malé. Ano, ovlivní to plánování. Tohle bude bolet. A asi nejtěžší na této praxi je zvyknout si na členění úkolů, tedy jak to udělat, abyste si něco vzali a udělali to za pár hodin a zároveň prošli revizí, pokud ty máš jeden. Recenze je samostatná bolest.
Unit testy jsou pouze pomocníkem, který vám pomůže pochopit, zda byla vaše integrace úspěšná a zda se nic nezlomilo. Podle mého názoru to také není zcela povinné, protože o to nejde.
Toto je stručný úvod do průběžné integrace. To je vše, co k této praxi patří. Jsem připraven na otázky.
Znovu to jen krátce shrnu:
- Continuous Integration není Jenkins, není to Gitlab.
- Toto není nástroj, je to praxe, že náš kód začleňujeme do hlavního tak často, jak je to možné.
- Děláme to proto, abychom se vyhnuli obrovské bolesti, která vzniká při splynutí v budoucnu, to znamená, že nyní zažíváme trochu bolesti, abychom v budoucnu nezažili více. To je celá podstata.
- Na straně je komunikace pomocí kódu, ale to vidím velmi zřídka, ale také to bylo navrženo.
otázky
Co dělat s nerozloženými úkoly?
Rozložit. Co je za problém? Můžete uvést příklad, že existuje úkol a není rozložen?
Jsou úkoly, které se nedají rozložit od slova „zcela“, například takové, které vyžadují velmi hlubokou odbornost a které lze skutečně vyřešit během měsíce k dosažení nějakého stravitelného výsledku.
Jestli vám dobře rozumím, tak je tu nějaký velký a složitý úkol, jehož výsledek bude viditelný až za měsíc?
Ano to je správně. Ano, vyhodnotit výsledek bude možné nejdříve za měsíc.
Pokuta. Obecně to není problém. Proč? Protože v tomto případě, když mluvíme o větvičkách, nemluvíme o větvičce s rysem. Funkce mohou být velké a složité. Mohou ovlivnit velké množství komponent. A možná je nemůžeme dělat úplně v jednom oboru. Tohle je fajn. Tento příběh prostě potřebujeme rozebrat. Pokud funkce není zcela připravena, neznamená to, že některé části jejího kódu nelze sloučit. Přidali jste, řekněme, migraci a uvnitř funkce jsou některé fáze. Řekněme, že máte fázi – proveďte migraci, přidejte novou metodu. A tyhle věci už můžete měřit každý den.
Pokuta. Jaký to má smysl?
Jaký má smysl zabíjet každý den malé věci?
Ano.
Pokud něco rozbijí, hned to vidíte. Máte malý kousek, který něco rozbil, je pro vás snazší to opravit. Jde o to, že sloučit malý kousek teď je mnohem jednodušší než sloučit něco velkého za pár týdnů. A třetí bod je, že ostatní inženýři budou pracovat s aktuální verzí kódu. Uvidí, že sem byly přidány nějaké migrace, a pak se objevila nějaká metoda, kterou by také mohli chtít použít. Všichni uvidí, co se děje ve vašem kódu. Pro tyto tři věci se praktikuje.
Děkujeme, problém je uzavřen!
(Oleg Soroka) Mohu přidat? Řekl jsi vše správně, jen bych chtěl přidat jednu frázi.
Takže
Díky kontinuální integraci se kód sloučí do společné větve nikoli, když je funkce zcela připravena, ale když se sestavení přestane rušit. A můžete se bezpečně zavázat ke zvládnutí tolikrát za den, kolikrát chcete. Druhým aspektem je, že pokud z nějakého důvodu nemůžete rozdělit měsíční úkol na úkoly alespoň tři dny, já mlčím asi tři hodiny, pak máte obrovský problém. A skutečnost, že nemáte kontinuální integraci, je nejmenší z těchto problémů. To znamená, že máte problémy s architekturou a nulovou inženýrskou praxí. Protože i když jde o výzkum, tak v každém případě musí být formulován ve formě hypotéz nebo cyklu.
Mluvili jsme o 4 metrikách, které odlišují úspěšné firmy od těch zaostávajících. Těchto 4 metrik se ještě musíme dožít. Pokud váš průměrný úkol trvá měsíc, pak bych se nejprve zaměřil na tuto metriku. Nejprve bych to snížil na 3 dny. A poté jsem začal přemýšlet o Continuous.
Rozuměl jsem vám správně, že si myslíte, že obecně nemá smysl investovat do inženýrských praxí, když nějaký úkol trvá měsíc?
Máte průběžnou integraci. A existuje takové téma, že za 10 minut buď opravíte, nebo vrátíte zpět. Představte si, že jste to rozbalili. Navíc máte dokonce nepřetržité nasazení, spustili jste to prod a teprve pak jste si všimli, že se něco pokazilo. A musíte to vrátit zpět, ale již jste migrovali svou databázi. Databázové schéma příští verze už máte, navíc jste měli i nějakou zálohu a tam se zapisovala i data.
A jakou máte alternativu? Pokud kód vrátíte zpět, nebude již moci s touto aktualizovanou databází pracovat.
Základna se pohybuje pouze dopředu, ano.
Lidé, kteří mají špatné technické postupy, s největší pravděpodobností nečetli tlustou knihu o... Co dělat se zálohou? Pokud obnovujete ze zálohy, znamená to, že ztratíte data, která jste za tu chvíli nashromáždili. Například s novou verzí databáze jsme pracovali tři hodiny, uživatelé se tam registrovali. Odmítnete starou zálohu, protože schéma nefunguje s novou verzí, takže jste o tyto uživatele přišli. A jsou nespokojení, nadávají.
Abyste zvládli celou řadu praktik, které podporují kontinuální integraci a kontinuální doručování, nestačí se jen naučit psát.... Jednak jich může být hodně, bude to nepraktické. Navíc existuje spousta dalších postupů, jako je Scientific. Existuje taková praxe, GitHub ji svého času popularizoval. To je, když máte současně spuštěný starý i nový kód. To je, když vytvoříte nedokončenou funkci, ale může vrátit nějakou hodnotu: buď jako funkci, nebo jako Rest API. Spustíte nový i starý kód a porovnáte rozdíl mezi nimi. A pokud existuje rozdíl, zaznamenáte tuto událost. Tímto způsobem budete vědět, že máte připravenou novou funkci, kterou můžete zavést nad starou, pokud mezi nimi po určitou dobu nebyl nesoulad.
Takových praktik jsou stovky. Navrhoval bych začít s vývojem transbase. Není 100% na kontinuální integraci, ale praktiky jsou stejné, jedna bez druhé nemůže dobře žít.
Uvedl jste rozvoj transbase jako příklad, kde můžete vidět praktiky, nebo navrhujete, aby lidé začali používat rozvoj transbase?
Podívejte se, protože to nebudou moci použít. Abyste je mohli používat, musíte hodně číst. A když se někdo zeptá: „Co dělat s funkcí, která trvá měsíc, znamená to, že nečetl o vývoji transbase.“ Zatím bych to nedoporučoval. Doporučil bych zaměřit se výhradně na téma, jak správně architektonicky rozčlenit velké úkoly na menší. To je podstata rozkladu.
Dekompozice je jedním z nástrojů architekta. Nejprve provedeme analýzu, poté rozklad, poté syntézu a poté integraci. A takhle nám to všechno vychází. A stále potřebujeme dorůst do kontinuální integrace prostřednictvím rozkladu. Otázky vyvstávají v první fázi, a to už mluvíme o fázi čtvrté, tedy čím častěji integraci provádíme, tím lépe. Na to je ještě příliš brzy; bylo by hezké nejprve pokácet svůj monolit.
Na nějakém diagramu musíte nakreslit řadu šipek a čtverců. Nemůžete říci, že nyní ukážu architektonický diagram nové aplikace a ukážu jeden čtverec, uvnitř kterého je zelené tlačítko pro aplikaci. V každém případě bude více čtverečků a šipek. Každý diagram, který jsem viděl, měl více než jeden. A rozklad i na úrovni grafického znázornění již probíhá. Proto mohou být čtverce nezávislé. Pokud ne, pak mám na architekta velké otázky.
Z chatu je otázka: „Pokud je kontrola povinná a trvá dlouho, možná den nebo déle?“
Máte problémy s praxí. Kontrola by neměla trvat den nebo déle. Toto je stejný příběh jako u předchozí otázky, jen trochu měkčí. Pokud recenze trvá jeden den, pak s největší pravděpodobností tato recenze prochází velmi velkou změnou. To znamená, že je potřeba jej zmenšit. Ve vývoji transbase, který Oleg doporučil, existuje příběh zvaný kontinuální recenze. Její představa je, že takový malý pull request děláme záměrně, protože se snažíme splývat neustále a po troškách. A tak pull request změní jednu abstrakci nebo 10 řádků. Díky této recenzi nám to zabere pár minut.
Pokud kontrola trvá den nebo déle, něco není v pořádku. Za prvé, můžete mít nějaké problémy s architekturou. Nebo se jedná o velký kus kódu, například 1 řádků. Nebo je vaše architektura tak složitá, že jí člověk nerozumí. To je trochu okrajový problém, ale bude se muset také vyřešit. Recenze snad není vůbec potřeba. I na toto musíme myslet. Recenze je věc, která vás zpomaluje. Má to obecně své výhody, ale musíte pochopit, proč to děláte. Je to pro vás způsob, jak rychle předat informace, je to způsob, jak si interně nastavit nějaké standardy nebo co? Proč to potřebuješ? Protože revize je potřeba udělat buď velmi rychle, nebo úplně zrušit. Je to jako vývoj transbase - příběh je velmi krásný, ale jen pro zralé chlapy.
Pokud jde o 4 metriky, stále bych je doporučil odstranit, abyste pochopili, k čemu to vede. Podívejte se na čísla, podívejte se na obrázek, jak je všechno špatné.
(Dmitry) Jsem připraven o tom s vámi diskutovat. Čísla a metriky jsou skvělé, praktiky jsou skvělé. Ale musíte pochopit, zda to podnik potřebuje. Jsou podniky, které takovou rychlost změn nepotřebují. Znám firmy, kde nelze provádět změny každých 15 minut. A ne proto, že by byli tak špatní. To je takový životní cyklus. A aby se funkce větví, funkce přepínání, potřebovala hluboké znalosti.
Je to komplikované. Pokud si chcete přečíst příběh o funkci přepínání podrobněji, vřele doporučuji . A existuje úžasný článek Martina Fowlera o funkcích přepínání: jaké existují typy, životní cykly atd. Funkce přepínání je komplikovaná.
A stále jste neodpověděli na otázku: "Je Jenkins potřeba, nebo ne?"
Jenkins není v žádném případě opravdu potřeba. Ale vážně, nástroje: Jenkins, Gitlab vám přinesou pohodlí. Uvidíte, že sestava je sestavená nebo nesestavená. Mohou vám pomoci, ale nedají vám praxi. Mohou vám dát pouze kruh - Ok, ne Ok. A pak, když píšeš i testy, protože když testy nejsou, tak je to skoro bezpředmětné. Proto je to potřeba, protože je to pohodlnější, ale obecně se bez toho dá žít, moc neztratíte.
To znamená, že pokud máte praktiky, znamená to, že je nepotřebujete?
To je správně. Doporučuji test Jeze Humble. Tam mám k poslednímu bodu ambivalentní postoj. Ale obecně, pokud máte tři věci, neustále se slučujete, spouštíte testy na odevzdání v masteru, rychle opravujete sestavení v masteru, pak možná nic dalšího nepotřebujete.
Zatímco čekáme na dotazy účastníků, mám otázku. Mluvili jsme jen o kódu produktu. Použili jste to pro kód infrastruktury? Je to stejný kód, má stejné principy a stejný životní cyklus, nebo existují různé životní cykly a principy? Obvykle, když všichni mluví o kontinuální integraci a rozvoji, všichni zapomínají, že existuje také kód infrastruktury. A v poslední době je toho čím dál tím víc. A měla by tam být vnesena všechna tato pravidla?
Ani ne, že by to mělo být, bylo by to skvělé, protože by to stejným způsobem usnadnilo život. Jakmile pracujeme s kódem, ne s bash skripty, ale máme normální kód.
Stop, stop, bash skript je také kód. Nedotýkej se mé staré lásky.
Dobře, nebudu šlapat po tvých vzpomínkách. Osobně nemám rád bash. Celou dobu se to ošklivě a děsivě láme. A často se nepředvídatelně rozbije, a proto se mi to nelíbí. Ale dobře, řekněme, že máte bash kód. Možná tomu opravdu nerozumím a existují normální testovací rámce. Jen se v tom nevyznám. A získáváme stejné výhody.
Jakmile pracujeme s infrastrukturou jako s kódem, dostáváme všechny stejné problémy jako vývojáři. Před pár měsíci jsem se setkal se situací, kdy mi kolega poslal pull request na 1 řádků v bash. A vy se 000 hodiny poflakujete u recenze. Objevují se stejné problémy. Pořád je to kód. A pořád je to spolupráce. Zasekneme se u pull requestu a zasekneme se u toho, že řešíme stejné konflikty sloučení například ve stejném bashu.
Nyní se na to celé velmi aktivně dívám na nejkrásnějším infra programování. Nyní jsem přivedl Pulumi do infrastruktury. Toto je programování ve své nejčistší podobě. Tam je to ještě hezčí, protože mám všechny možnosti programovacího jazyka, tj. udělal jsem z ničeho nic krásný toggle se stejnými if a vše je v pořádku. To znamená, že moje změna je již v předloze. Všichni už ho vidí. Ostatní inženýři o tom vědí. Už to tam něco ovlivnilo. Nebyl však povolen pro všechny infrastruktury. Zapnulo se to například pro mé zkušební stolice. Proto, abychom znovu odpověděli na vaši otázku, je nutné. Stejným způsobem to usnadňuje život nám jako inženýrům pracujícím s kódem.
Pokud má někdo další otázky?
Mám otázku. Chci pokračovat v diskusi s Olegem. Obecně si myslím, že máš pravdu, že když úkol trvá měsíc, tak máš problém s architekturou, máš problém s analýzou, rozkladem, plánováním atd. Ale mám pocit, že když začneš snažíte se žít podle kontinuální integrace, pak začnete bolest napravovat plánováním, protože jinam se od ní nedostanete.
(Oleg) Ano, je to tak. Tato praxe je svým úsilím srovnatelná s jakoukoli jinou seriózní praxí měnící kulturu. Nejtěžší je překonat návyky, zvláště zlozvyky. A pokud je k implementaci této praxe nutná vážná změna ve zvycích lidí kolem vás: vývojáři, management, vedoucí výroby, pak na vás čekají překvapení.
Jaká překvapení by mohla být? Řekněme, že se rozhodnete, že se budete integrovat častěji. A máte nějaké další věci spojené s integrací, například artefakty. A ve vaší firmě například platí zásada, že každý artefakt musí být nějakým způsobem zaúčtován v nějakém systému ukládání artefaktů. A to nějakou dobu trvá. Osoba musí zaškrtnout políčko, že jako správce vydání testoval tento artefakt, aby se ujistil, že je připraven k vydání v produkci. Pokud to trvá 5-10-15 minut, ale rozvržení děláte jednou týdně, pak je strávit půl hodiny jednou týdně malou daní.
Pokud provádíte kontinuální integraci 10krát denně, pak je třeba 10krát vynásobit 30 minutami. A to přesahuje množství pracovní doby tohoto správce vydání. Prostě ho to unavuje. U některých praktik jsou fixní náklady. To je vše.
A toto pravidlo musíte buď zrušit, abyste už nedělali takové zmetky, čili ručně nepřidělujete stupeň, který něčemu odpovídá. Zcela se spoléháte na nějakou automatizovanou sadu testů připravenosti.
A pokud od někoho potřebujete důkaz, aby to šéf podepsal, a vy se nedostanete do výroby, aniž by Vasya řekl, že to povoluje atd. - všechny tyhle nesmysly se praktikujícímu připletou do cesty. Protože pokud jsou nějaké činnosti spojené s daní, tak se vše 100x zvyšuje. Směnu proto často nepřivítají všichni s radostí. Protože návyky lidí se těžko mění.
Když člověk dělá svou obvyklou práci, dělá ji téměř bez přemýšlení. Její kognitivní zátěž je nulová. Jen si s tím hraje, už má v hlavě kontrolní seznam, udělal to tisíckrát. A jakmile přijdete a řeknete mu: „Zrušme tuto praxi a od pondělí zaveďme novou,“ pro něj se to stane silnou kognitivní zátěží. A přijde na všechny najednou.
Proto nejjednodušší věc, i když ne každý si může dovolit tento luxus, ale to je to, co dělám vždy, je to následující. Pokud se rozjede nový projekt, pak se většinou všechny nevyzkoušené praktiky okamžitě nacpou do tohoto projektu. I když je projekt mladý, opravdu nic neriskujeme. Zatím není žádný Prod, není co zničit. Proto může být použit jako trénink. Tento přístup funguje. Ne všechny firmy ale mají možnost takové projekty často rozjíždět. I když je to také trochu zvláštní, protože nyní probíhá kompletní digitální transformace, každý musí začít experimentovat, aby udržel krok s konkurencí.
Zde dojdete k závěru, že nejprve musíte pochopit, co musíte udělat. Svět není ideální a ani prod není ideální.
Ano, tyto věci spolu souvisí.
Firmy také ne vždy chápou, že musí jít touto cestou.
Nastává situace, kdy nejsou možné vůbec žádné změny. To je situace, kdy je na tým větší tlak. Tým je už dost vyhořelý. Nemá čas na žádné experimenty. Na funkcích pracují od rána do večera. A řízení má stále méně funkcí. Je potřeba stále více. V takové situaci nejsou možné vůbec žádné změny. Týmu lze pouze říci, že zítra budeme dělat totéž, co včera, jen potřebujeme udělat trochu více funkcí. V tomto smyslu nejsou možné žádné přechody k jakýmkoli praktikám. Jde o klasickou situaci, kdy není čas na broušení sekery, je potřeba kácet stromy, tak ji řežou tupou sekerou. Neexistují zde žádné jednoduché tipy.
(Dmitry) Přečtu si vysvětlení z chatu: „Potřebujeme ale hodně testovacího pokrytí na různých úrovních. Kolik času je vyhrazeno na testy? Je to trochu drahé a zabere to spoustu času."
(Oleg) To je klasická mylná představa. Testů by mělo být dost, abyste si byli jisti. Nepřetržitá integrace není věc, kdy se nejprve provede 100 % testů a teprve poté začnete tuto praxi aplikovat. Nepřetržitá integrace snižuje vaši kognitivní zátěž díky tomu, že každá ze změn, které vidíte očima, je tak zřejmá, že i bez testů pochopíte, zda něco rozbije nebo ne. Můžete si to rychle otestovat v hlavě, protože změny jsou malé. I když máte pouze ruční testery, je to pro ně také jednodušší. Vyvalil ses a řekl jsi: "Podívej, je něco rozbité?" Zkontrolovali to a řekli: "Ne, nic není rozbité." Protože tester ví, kde hledat. Máte jedno potvrzení spojené s jedním kusem kódu. A toho se využívá specifickým chováním.
Zde si samozřejmě přikrášlil.
(Dmitry) Tady nesouhlasím. Existuje praxe - vývoj řízený testem, který vás toho zachrání.
(Oleg) No, k tomu jsem se ještě nedostal. První iluzí je, že musíte napsat 100 % testů nebo nemusíte kontinuální integraci dělat vůbec. To není pravda. To jsou dvě paralelní praktiky. A nejsou přímo závislé. Vaše testovací pokrytí musí být optimální. Optimální - to znamená, že vy sami jste si jisti, že kvalita masteru, ve kterém váš master zůstal po odevzdání, vám umožní s jistotou stisknout tlačítko „Deploy“ v opilém pátečním večeru. Jak toho dosáhnete? Prostřednictvím přezkumu, prostřednictvím pokrytí, prostřednictvím dobrého monitorování.
Dobrý monitoring je k nerozeznání od testů. Pokud jednou spustíte testy na předprodukci, pak jednou zkontrolují všechny vaše uživatelské skripty a je to. A pokud je spouštíte v nekonečné smyčce, pak je to váš nasazený monitorovací systém, který donekonečna testuje vše – ať už spadl nebo ne. V tomto případě je rozdíl pouze v tom, zda se to udělá raz nebo dvakrát. Velmi dobrá sada testů... běží nekonečně, to je monitorování. A správné sledování by mělo být takové.
A proto, jak přesně tohoto stavu dosáhnete, až se v pátek večer připravíte a půjdete domů, je jiná otázka. Možná jsi jen smělý zmetek.
Vraťme se trochu k průběžné integraci. Utekli jsme do trochu jiné složité praxe.
A druhá iluze je, že MVP je prý potřeba udělat rychle, takže tam testy vůbec nejsou potřeba. Tímto způsobem určitě ne. Faktem je, že když napíšete uživatelský příběh do MVP, můžete jej buď vyvinout na kouli, to znamená, že jste slyšeli, že existuje nějaký uživatelský příběh, a okamžitě jste jej běželi kódovat, nebo můžete pracovat pomocí TDD. A podle TDD, jak ukazuje praxe, to netrvá déle, tj. testy jsou vedlejším účinkem. Praxe TDD není o testování. Navzdory tomu, co se nazývá Test Driven Development, o testy vůbec nejde. To je také spíše architektonický přístup. Jedná se o přístup k psaní přesně toho, co je potřeba, a nikoli psaní toho, co není potřeba. Toto je praxe zaměřená na další iteraci vašeho myšlení ve smyslu vytváření aplikační architektury.
Proto není tak snadné se těchto iluzí zbavit. MVP a testy si neodporují. Dokonce, spíše naopak, když děláš MVP pomocí TDD tréninku, tak to uděláš lépe a rychleji, než když to budeš dělat úplně bez tréninku, ale na míči.
To je velmi nesrozumitelná a komplexní myšlenka. Když slyšíte, že teď budu psát další testy a zároveň budu dělat něco rychleji, zní to naprosto neadekvátně.
(Dmitry) Mnoho lidí tady, když volají MVP, jsou příliš líní napsat něco normálního. A to jsou ještě různé věci. Není třeba měnit MVP v nějakou špatnou věc, která nefunguje.
Ano, ano, máte pravdu.
A pak najednou MVP v prod.
Navždy a napořád.
A TDD zní velmi neobvykle, když slyšíte, že píšete testy a zdá se, že děláte více práce. Zní to velmi zvláštně, ale ve skutečnosti je to takto rychlejší a hezčí. Když píšete test, v hlavě už hodně přemýšlíte o tom, jaký kód se bude jmenovat a jak, a také jaké chování od něj očekáváme. Neříkáte jen, že jsem napsal nějakou funkci a ta něco udělá. Nejprve jste si mysleli, že má takové a takové stavy, bude volána tak a tak. Pokryjete to testy a z toho pochopíte, jak budou vaše rozhraní vypadat uvnitř vašeho kódu. To má obrovský dopad na architekturu. Váš kód se automaticky stane modulárnějším, protože se nejprve pokusíte pochopit, jak jej budete testovat, a teprve poté jej napíšete.
S TDD se mi stalo, že jsem v určitém okamžiku najal mentora Ruby, když jsem byl ještě programátorem Ruby. A on říká: "Udělejme to podle TDD." Pomyslel jsem si: "Sakra, teď musím napsat něco navíc." A dohodli jsme se, že do dvou týdnů napíšu veškerý pracovní kód v Pythonu pomocí TDD. Po dvou týdnech jsem si uvědomil, že se nechci vrátit. Po dvou týdnech, kdy se to snažíte aplikovat všude, si uvědomíte, jak je pro vás snazší i jen přemýšlet. To ale není samozřejmé, proto všem doporučuji, pokud máte pocit, že TDD je obtížné, časově náročné a zbytečné, zkuste u toho vydržet jen dva týdny. Dva mi stačily.
(Dmitry) Tuto myšlenku můžeme rozšířit z hlediska provozu infrastruktury. Než spustíme něco nového, provedeme monitorování a poté spustíme. V tomto případě se pro nás sledování stává běžným testováním. A tam je vývoj prostřednictvím sledování. Ale skoro všichni říkají, že je to dlouhé, jsem líný, udělal jsem dočasný koncept. Pokud jsme provedli normální monitorování, rozumíme stavu systému CI. A systém CI má hodně monitorování. Chápeme stav systému, chápeme, co je uvnitř. A při vývoji teprve děláme systém tak, aby dosáhl požadovaného stavu.
Tyto praktiky jsou známy již dlouhou dobu. Diskutovali jsme o tom asi před 4 lety. Ale za 4 roky se prakticky nic nezměnilo.
Ale na tuto poznámku navrhuji ukončit oficiální diskusi.
Video (vloženo jako mediální prvek, ale z nějakého důvodu nefunguje):
Zdroj: www.habr.com