Poďme diskutovať o tom, prečo sú CI nástroje a CI úplne odlišné veci.
Akú bolesť má CI riešiť, odkiaľ prišiel nápad, aké sú najnovšie potvrdenia, že to funguje, ako pochopiť, že máte prax a nie len nainštalovaného Jenkinsa.
Nápad urobiť reportáž o kontinuálnej integrácii sa objavil pred rokom, keď som chodil na pohovory a hľadal si prácu. Hovoril som s 10-15 spoločnosťami, iba jedna z nich bola schopná jasne odpovedať, čo je CI a vysvetliť, ako si uvedomili, že ju nemajú. Ostatní hovorili o Jenkinsovi nezrozumiteľné nezmysly :) No, máme Jenkinsa, stavia sa, CI! Počas správy sa pokúsim vysvetliť, čo to vlastne kontinuálna integrácia je a prečo k tomu majú Jenkins a podobné nástroje veľmi slabý vzťah.
Čo vám teda zvyčajne napadne, keď počujete slovo CI? Väčšina ľudí si predstaví Jenkins, Gitlab CI, Travis atď.
Aj keď si to vygooglime, dá nám tieto nástroje.
Ak ste oboznámení s pýtaním sa, potom vám hneď po uvedení nástrojov povedia, že CI je, keď vytvárate a spúšťate testy v Pull Request pre odovzdanie.
Kontinuálna integrácia nie je o nástrojoch, nie o zostavách s testami v pobočke! Kontinuálna integrácia je prax veľmi častej integrácie nového kódu a na jej použitie nie je vôbec potrebné ohradzovať Jenkins, GitLab atď.
Než prídeme na to, ako vyzerá plnohodnotný CI, ponorme sa najprv do kontextu ľudí, ktorí s ním prišli a pocítime bolesť, ktorú sa snažili vyriešiť.
A vyriešili bolesť zo spoločnej práce ako tím!
Pozrime sa na príklady ťažkostí, s ktorými sa vývojári stretávajú pri vývoji v tímoch. Tu máme projekt, hlavnú vetvu v git a dvoch vývojárov.
A dali sa do práce tak, ako boli všetci dávno zvyknutí. Zobrali sme úlohu vo veľkej schéme vecí, vytvorili sme vetvu funkcií a napísali kód.
Jeden dokončil funkciu rýchlejšie a zlúčil ju do predlohy.
Druhý potreboval viac času, neskôr sa spojil a skončil konfliktom. Teraz namiesto písania funkcií, ktoré podnik potrebuje, trávi vývojár svoj čas a energiu riešením konfliktov.
Čím ťažšie je skĺbiť vašu vlastnosť so spoločným majstrom, tým viac času tomu venujeme. A ukázal som to na celkom jednoduchom príklade. Toto je príklad, kde sú vývojári iba 2. Predstavte si, že do jedného úložiska píše 10 alebo 15 alebo 100 ľudí vo firme. Budete sa zblázniť, aby ste vyriešili všetky tieto konflikty.
Existuje trochu iný prípad. Máme majstra a niektorých vývojárov, ktorí niečo robia.
Vytvorili vetvičku.
Jeden zomrel, všetko bolo v poriadku, úlohu zložil.
Druhý vývojár medzitým odovzdal svoju úlohu. Povedzme, že to poslal na kontrolu. Mnoho spoločností má prax nazývanú recenzia. Na jednej strane je táto prax dobrá a užitočná, na druhej strane nás v mnohom spomaľuje. Nebudeme sa tým zaoberať, ale tu je skvelý príklad toho, k čomu môže viesť zlá recenzia. Odoslali ste žiadosť o stiahnutie na kontrolu. Viac už vývojár nemusí robiť. Čo začne robiť? Začína sa venovať iným úlohám.
Počas tejto doby urobil druhý vývojár niečo iné.
Prvý splnil tretiu úlohu.
A po nejakom dlhom čase bola jeho recenzia testovaná a snaží sa prísť na to. Tak čo sa deje? Zachytáva obrovské množstvo konfliktov. prečo? Pretože zatiaľ čo jeho požiadavka na stiahnutie visela v recenzii, veľa vecí sa už v kóde zmenilo.
Okrem príbehu s konfliktmi je tu príbeh s komunikáciami. Zatiaľ čo vaše vlákno visí na kontrole, zatiaľ čo na niečo čaká, kým dlho pracujete na nejakej funkcii, prestávate sledovať, čo sa ešte mení v kódovej základni vašej služby. Možno to, čo sa teraz snažíte vyriešiť, už bolo vyriešené včera a môžete použiť nejakú metódu a znova ju použiť. Ale toto neuvidíte, pretože vždy pracujete so zastaranou pobočkou. A táto zastaraná vetva vždy vedie k tomu, že musíte vyriešiť konflikt zlučovania.
Ukazuje sa, že ak pracujeme ako tím, t. j. v úložisku sa nehrabe jedna osoba, ale 5-10 ľudí, tak čím dlhšie nepridávame náš kód do hlavného servera, tým viac trpíme, pretože v konečnom dôsledku potrebujeme niečo potom zlúčiť. A čím viac konfliktov máme a s čím staršou verziou pracujeme, tým viac problémov máme.
Robiť niečo spolu je bolestivé! Vždy si prekážame.
Tento problém bol zaznamenaný pred viac ako 20 rokmi. Prvú zmienku o praxi kontinuálnej integrácie som našiel v extrémnom programovaní.
Extrémne programovanie je prvý agilný rámec. Stránka sa objavila v roku 96. A myšlienka bola použiť nejaké programátorské praktiky, plánovanie a iné veci, aby bol vývoj čo najflexibilnejší, aby sme vedeli rýchlo reagovať na prípadné zmeny či požiadavky našich klientov. A s tým sa začali stretávať pred 24 rokmi, že ak niečo robíte veľmi dlho a okrajovo, tak tomu venujete viac času, lebo máte konflikty.
Teraz budeme jednotlivo analyzovať frázu „Nepretržitá integrácia“. Ak to preložíme priamo, dostaneme kontinuálnu integráciu. Ale ako je to spojité, nie je veľmi jasné; je to veľmi nespojité. Ale to, koľko integrácie má, tiež nie je príliš zrejmé.
A preto vám teraz dávam citáty z Extrémneho programovania. A obe slová rozoberieme samostatne.
Integrácia – Ako som už povedal, snažíme sa o to, aby každý inžinier pracoval s najaktuálnejšou verziou kódu, aby sa snažil pridávať svoj kód čo najčastejšie do spoločnej vetvy, aby to boli malé vetvy. Pretože ak sú veľké, ľahko sa môžeme na týždeň zaseknúť pri zlučovacích konfliktoch. To platí najmä vtedy, ak máme dlhý vývojový cyklus, ako je vodopád, kde vývojár odišiel na mesiac, aby vystrihol nejakú obrovskú funkciu. A vo fáze integrácie bude uviaznutý na veľmi dlhú dobu.
Integrácia je, keď vezmeme svoju ratolesť a integrujeme ju s pánom, zlúčime ju. Je tu konečná možnosť, keď sme vývojárom transbase, kde sa snažíme zabezpečiť, aby sme okamžite zapisovali do hlavného zariadenia bez akýchkoľvek ďalších vetiev.
Vo všeobecnosti integrácia znamená vziať váš kód a pretiahnuť ho do hlavného servera.
Čo sa tu myslí pod slovom „nepretržitý“, čo sa nazýva kontinuita? Prax znamená, že vývojár sa snaží integrovať svoj kód čo najrýchlejšie. To je jeho cieľom pri vykonávaní akejkoľvek úlohy – dostať svoj kód do mastera čo najrýchlejšie. V ideálnom svete by to vývojári robili každých pár hodín. To znamená, že vezmete malý problém a zlúčite ho do hlavného. Všetko je skvelé. To je to, o čo sa snažíte. A to sa musí robiť nepretržite. Akonáhle niečo urobíte, okamžite to vložíte do majstra.
A vývojár, ktorý niečo vyrába, je zodpovedný za to, čo urobil, aby to fungovalo a nič nepokazil. Tu zvyčajne vychádza testovací príbeh. Chceme vykonať nejaké testy na našom odovzdaní, na našom zlúčení, aby sme sa uistili, že to funguje. A práve tu vám Jenkins môže pomôcť.
Ale s príbehmi: urobme zmeny malé, nechajme úlohy malé, urobme problém a okamžite ho skúsme nejako zakomponovať do mastera – tu nepomôže žiaden Jenkins. Pretože Jenkins vám pomôže iba spustiť testy.
Môžete to urobiť bez nich. Toto ti vôbec neublíži. Pretože cieľom praxe je merať čo najčastejšie, aby sa v budúcnosti nestrácalo obrovské množstvo času na prípadné konflikty.
Predstavme si, že z nejakého dôvodu sme v roku 2020 bez internetu. A pracujeme lokálne. Nemáme Jenkinsa. Toto je fajn. Stále môžete pokračovať a vytvoriť miestnu pobočku. Napísal si tam nejaký kód. Úlohu sme splnili za 3-4 hodiny. Prešli sme na master, urobili sme git pull a zlúčili sme tam našu pobočku. Pripravený. Ak to robíte často, gratulujeme, máte nepretržitú integráciu!
Aké dôkazy v modernom svete existujú, že sa oplatí míňať energiu? Pretože vo všeobecnosti je to ťažké. Ak sa pokúsite takto pracovať, pochopíte, že niektoré plánovanie bude teraz ovplyvnené, budete musieť venovať viac času rozkladaniu úloh. Pretože ak to urobíš človeče..., tak sa nebudeš vedieť rýchlo dohodnúť a podľa toho sa dostaneš do problémov. Už nebudete mať prax.
A bude to drahé. Od zajtra nebude možné okamžite pracovať pomocou nepretržitej integrácie. Všetkým vám bude veľmi dlho trvať, kým si na to zvyknete, bude vám trvať veľmi dlho, kým si zvyknete na rozkladové úlohy, bude vám trvať veľmi dlho, kým si zvyknete na prepracovanie kontrolnej praxe, ak ju máte . Pretože naším cieľom je, aby sa to dnes roztopilo. A ak urobíte kontrolu do troch dní, potom máte problémy a nepretržitá integrácia pre vás nefunguje.
Ale máme teraz nejaké relevantné dôkazy, ktoré nám hovoria, že investovanie do tejto praxe má zmysel?
Prvá vec, ktorá mi napadla, bol State of DevOps. Toto je štúdia, ktorú chalani vykonávajú už 7 rokov. Teraz to robia ako nezávislá organizácia, ale pod spoločnosťou Google.
A ich štúdia z roku 2018 ukázala koreláciu medzi spoločnosťami, ktoré sa snažia využívať pobočky s krátkou životnosťou, ktoré sa integrujú rýchlo, často sa integrujú a majú lepšie ukazovatele výkonnosti IT.
Aké sú tieto ukazovatele? Toto sú 4 metriky, ktoré vo svojich dotazníkoch berú od všetkých spoločností: frekvencia nasadenia, čas potrebný na zmeny, čas na obnovenie služby, miera zlyhania zmien.
A po prvé, je tu táto korelácia, vieme, že spoločnosti, ktoré merajú často, majú oveľa lepšie metriky. A majú rozdelenie spoločností do niekoľkých kategórií: sú to pomalé spoločnosti, ktoré vyrábajú niečo pomaly, stredne výkonné, vysoko výkonné a elitné. Elitou sú Netflix, Amazon, ktoré sú super rýchle, všetko robia rýchlo, krásne a efektívne.
Druhý príbeh, ktorý sa stal len pred mesiacom. Technology Radar má skvelý článok o Gitflow. Gitflow sa líši od všetkých ostatných tým, že jeho vetvy sú dlhoveké. Existujú uvoľňovacie vetvy, ktoré žijú dlho, a predstavujú vetvy, ktoré tiež žijú dlho. Táto prax v Technologickom radare sa presunula na HOLD. prečo? Pretože ľudia čelia bolesti integrácie.
Ak vaša ratolesť žije veľmi dlho, zasekne sa, zhnije a my začneme tráviť viac času snahou o nejakú zmenu.
A nedávno autor Gitflow povedal, že ak je vaším cieľom kontinuálna integrácia, ak je vaším cieľom to, aby ste chceli rolovať čo najčastejšie, potom je Gitflow zlý nápad. Samostatne k článku dodal, že ak máte backend, kde sa o to môžete snažiť, tak Gitflow je pre vás zbytočný, pretože Gitflow vás bude spomaľovať, Gitflow vám bude robiť problémy s integráciou.
To neznamená, že Gitflow je zlý a nemal by sa používať. Je to na iné príležitosti. Napríklad, keď potrebujete podporovať niekoľko verzií služby alebo aplikácie, t. j. tam, kde potrebujete podporu na dlhú dobu.
Ale ak sa porozprávate s ľuďmi, ktorí podporujú takéto služby, budete počuť veľa bolesti o tom, že táto verzia bola 3.2, čo bolo pred 4 mesiacmi, ale táto oprava v nej nebola zahrnutá a teraz, aby sa to podarilo, musíte urobiť veľa zmien. A teraz opäť uviazli a teraz sa týždeň pokúšajú implementovať nejakú novú funkciu.
Ako správne poznamenal Alexander Kovalev v chate, korelácia nie je to isté ako príčinná súvislosť. Toto je pravda. To znamená, že neexistuje priame spojenie, že ak máte nepretržitú integráciu, všetky metriky budú skvelé. Existuje však pozitívna korelácia, že ak je jeden jeden, potom je s najväčšou pravdepodobnosťou aj druhý. Nie je to pravda, ale s najväčšou pravdepodobnosťou. Je to len korelácia.
Zdá sa, že už niečo robíme, zdá sa, že sa už spájame, ale ako pochopiť, že stále máme kontinuálnu integráciu, že sa pomerne často spájame?
Jez Humble je autorom príručky, zrýchlenia, webovej stránky Continuous Delivery a knihy Continuous Delivery. Ponúka tento test:
- Kód inžiniera sa dostane k majstrovi každý deň.
- Pre každé odovzdanie spustíte testy jednotiek.
- Stavba v predlohe spadla, bola opravená asi za 10 minút.
Navrhuje použiť takýto test, aby ste sa uistili, že máte dostatok praxe.
To posledné považujem za trochu kontroverzné. To znamená, že ak to dokážete opraviť za 10 minút, potom máte nepretržitú integráciu, znie to podľa mňa trochu zvláštne, ale dáva to zmysel. prečo? Pretože ak často mrznete, znamená to, že vaše zmeny sú malé. Ak malá zmena znamená, že vaša hlavná zostava je nefunkčná, potom môžete rýchlo nájsť príklad, pretože zmena je malá. Tu ste mali malé zlúčenie, zmenilo sa v ňom 20-30 riadkov. A podľa toho môžete rýchlo pochopiť, aký bol dôvod, pretože zmeny sú malé, máte veľmi malú oblasť na hľadanie problému.
A aj keď sa náš produkt po vydaní rozpadne, potom ak máme prax nepretržitej integrácie, je pre nás oveľa jednoduchšie konať, pretože zmeny sú malé. Áno, ovplyvní to plánovanie. Toto bude bolieť. A asi najťažšie na tejto praxi je zvyknúť si na rozpisovanie úloh, teda ako to urobiť, aby ste si niečo zobrali a urobili za pár hodín a zároveň prešli recenziou, ak jeden máš. Recenzia je samostatná bolesť.
Unit testy sú len pomocníkom, ktorý vám pomôže pochopiť, či bola vaša integrácia úspešná a či sa nič nepokazilo. Podľa mňa to tiež nie je úplne povinné, pretože o to nejde.
Toto je krátky úvod do kontinuálnej integrácie. To je všetko, čo sa týka tejto praxe. Som pripravený na otázky.
Ešte raz v krátkosti zhrniem:
- Continuous Integration nie je Jenkins, nie je to Gitlab.
- Toto nie je nástroj, je to prax, že zlučujeme náš kód do hlavného tak často, ako je to možné.
- Robíme to preto, aby sme sa vyhli obrovskej bolesti, ktorá vzniká pri splynutiach v budúcnosti, to znamená, že teraz zažijeme trochu bolesti, aby sme v budúcnosti nezažili viac. To je celá podstata.
- Na strane je komunikácia cez kód, ale to vidím veľmi zriedka, ale aj to je to, na čo bol navrhnutý.
otázky
Čo robiť s nerozloženými úlohami?
Rozložiť. Aký je problém? Môžete uviesť príklad, že existuje úloha a nie je rozložená?
Sú úlohy, ktoré sa nedajú rozložiť od slova „úplne“, napríklad také, ktoré si vyžadujú veľmi hlbokú odbornosť a ktoré sa dajú reálne vyriešiť v priebehu mesiaca, aby sa dosiahol nejaký stráviteľný výsledok.
Ak vám správne rozumiem, potom je tu nejaká veľká a zložitá úloha, ktorej výsledok bude viditeľný až za mesiac?
Áno, to je správne. Áno, výsledok bude možné vyhodnotiť najskôr o mesiac.
Dobre. Vo všeobecnosti to nie je problém. prečo? Pretože v tomto prípade, keď hovoríme o vetvičkách, nehovoríme o vetvičke s rysom. Funkcie môžu byť veľké a zložité. Môžu ovplyvniť veľké množstvo komponentov. A možno ich nemôžeme robiť úplne v jednom odvetví. Toto je fajn. Musíme len rozobrať tento príbeh. Ak funkcia nie je úplne pripravená, neznamená to, že niektoré časti jej kódu nemožno zlúčiť. Pridali ste, povedzme, migráciu a vo vnútri funkcie je niekoľko fáz. Povedzme, že máte fázu – urobte migráciu, pridajte novú metódu. A tieto veci už môžete merať každý deň.
Dobre. Aký to má potom zmysel?
Aký má zmysel zabíjať každý deň malé veci?
Áno.
Ak niečo rozbijú, hneď to vidíte. Máte malý kúsok, ktorý niečo rozbil, je pre vás jednoduchšie to opraviť. Ide o to, že zlúčiť malý kúsok teraz je oveľa jednoduchšie ako zlúčiť niečo veľké za pár týždňov. A tretím bodom je, že ostatní inžinieri budú pracovať s aktuálnou verziou kódu. Uvidia, že tu boli pridané nejaké migrácie a potom sa objavila metóda, ktorú by mohli chcieť použiť. Každý uvidí, čo sa deje vo vašom kóde. Pre tieto tri veci sa robí prax.
Ďakujeme, problém je uzavretý!
(Oleg Soroka) Môžem pridať? Všetko ste povedali správne, len chcem pridať jednu frázu.
Так.
Vďaka nepretržitej integrácii sa kód zlúči do spoločnej vetvy nie vtedy, keď je funkcia úplne pripravená, ale keď sa zostava prestane kaziť. A môžete sa bezpečne zaviazať, že budete ovládať toľkokrát za deň, koľko chcete. Druhým aspektom je, že ak z nejakého dôvodu nemôžete rozdeliť mesačnú úlohu na úlohy aspoň na tri dni, mlčím asi tri hodiny, potom máte obrovský problém. A skutočnosť, že nemáte nepretržitú integráciu, je najmenší z týchto problémov. To znamená, že máte problémy s architektúrou a nulovou inžinierskou praxou. Pretože aj keď ide o výskum, tak v každom prípade musí byť formulovaný vo forme hypotéz alebo cyklu.
Hovorili sme o 4 metrikách, ktoré odlišujú úspešné firmy od tých zaostávajúcich. Týchto 4 metrík sa ešte musíme dožiť. Ak vaša priemerná úloha trvá mesiac, potom by som sa najskôr zameral na túto metriku. Najprv by som to znížil na 3 dni. A potom som začal premýšľať o Continuous.
Rozumel som vám správne, že si myslíte, že vo všeobecnosti nemá zmysel investovať do inžinierskych postupov, ak splnenie akejkoľvek úlohy trvá mesiac?
Máte nepretržitú integráciu. A existuje taká téma, že za 10 minút môžete opraviť opravu alebo ju vrátiť späť. Predstavte si, že ste to rozbalili. Navyše máte dokonca nepretržité nasadzovanie, rozbalili ste to do výroby a až potom ste si všimli, že sa niečo pokazilo. A musíte to vrátiť späť, ale už ste migrovali svoju databázu. Databázovú schému ďalšej verzie už máte, navyše ste mali aj nejakú zálohu a boli tam zapísané aj údaje.
A akú máš alternatívu? Ak kód vrátite späť, potom už nebude môcť pracovať s touto aktualizovanou databázou.
Základňa sa posúva len dopredu, áno.
Ľudia, ktorí majú slabé inžinierske postupy, s najväčšou pravdepodobnosťou nečítali hrubú knihu o... Čo robiť so zálohou? Ak obnovíte zo zálohy, znamená to, že prídete o dáta, ktoré ste v danom momente nazhromaždili. Napríklad s novou verziou databázy sme pracovali tri hodiny, používatelia sa tam registrovali. Odmietnete starú zálohu, pretože schéma nefunguje s novou verziou, takže ste prišli o týchto používateľov. A sú nespokojní, nadávajú.
Aby ste zvládli celú škálu praktík, ktoré podporujú nepretržitú integráciu a nepretržité poskytovanie, nestačí sa len naučiť písať.... Po prvé, môže ich byť veľa, bude to nepraktické. Okrem toho existuje veľa ďalších postupov, ako je Scientific. Existuje taká prax, GitHub ju svojho času spopularizoval. To je, keď máte súčasne spustený starý aj nový kód. Toto je, keď vytvoríte nedokončenú funkciu, ale môže vrátiť určitú hodnotu: buď ako funkciu alebo ako Rest API. Spustíte nový kód aj starý kód a porovnáte rozdiel medzi nimi. A ak existuje rozdiel, zapíšte si túto udalosť. Týmto spôsobom viete, že máte pripravenú novú funkciu, ktorá sa má spustiť nad starou, ak medzi nimi už určitý čas nie je nezrovnalosť.
Takýchto praktík sú stovky. Navrhoval by som začať s vývojom transbase. Nie je 100% na kontinuálnej integrácii, ale praktiky sú rovnaké, jedna bez druhej nemôže dobre žiť.
Uviedli ste rozvoj transbase ako príklad, kde môžete vidieť praktiky, alebo navrhujete, aby ľudia začali využívať rozvoj transbase?
Pozrite sa, pretože to nebudú môcť použiť. Aby ste ich mohli používať, musíte veľa čítať. A keď sa niekto opýta: „Čo robiť s funkciou, ktorá trvá mesiac, znamená to, že nečítal o vývoji transbase.“ Zatiaľ by som to neodporúčal. Odporúčal by som zamerať sa výlučne na tému, ako správne architektonicky rozložiť veľké úlohy na menšie. Toto je podstata rozkladu.
Dekompozícia je jedným z nástrojov architekta. Najprv robíme analýzu, potom rozklad, potom syntézu a potom integráciu. A takto nám všetko vychádza. A stále musíme rásť k nepretržitej integrácii prostredníctvom rozkladu. Otázky vyvstávajú v prvej fáze a už hovoríme o štvrtej fáze, t. j. čím častejšie integráciu robíme, tým lepšie. Na to je ešte priskoro; bolo by pekné najprv zredukovať svoj monolit.
Na nejaký diagram musíte nakresliť niekoľko šípok a štvorcov. Nedá sa povedať, že teraz ukážem architektonickú schému novej aplikácie a ukážem jeden štvorec, vo vnútri ktorého je zelené tlačidlo pre aplikáciu. V každom prípade bude viac štvorcov a šípok. Každý diagram, ktorý som videl, mal viac ako jeden. A rozklad aj na úrovni grafického znázornenia už prebieha. Preto môžu byť štvorce nezávislé. Ak nie, potom mám na architekta veľké otázky.
Z chatu je otázka: „Ak je kontrola povinná a trvá dlho, možno deň alebo viac?“
Máte problémy s praxou. Kontrola by nemala trvať deň alebo viac. Toto je rovnaký príbeh ako v predchádzajúcej otázke, len trochu jemnejší. Ak recenzia trvá jeden deň, potom s najväčšou pravdepodobnosťou táto recenzia prechádza veľmi veľkou zmenou. To znamená, že ho treba zmenšiť. Vo vývoji transbase, ktorý Oleg odporučil, existuje príbeh nazývaný kontinuálna kontrola. Jej predstava je taká, že takú malú pull request robíme zámerne, pretože sa snažíme splývať neustále a po troškách. A tak požiadavka na stiahnutie zmení jednu abstrakciu alebo 10 riadkov. Vďaka tejto recenzii nám to zaberie pár minút.
Ak kontrola trvá deň alebo viac, niečo nie je v poriadku. Po prvé, môžete mať nejaké problémy s architektúrou. Alebo ide o veľký kus kódu, napríklad 1 000 riadkov. Alebo je vaša architektúra taká zložitá, že jej človek nerozumie. Je to trochu okrajový problém, ale aj ten bude treba vyriešiť. Recenziu snáď vôbec netreba. Musíme myslieť aj na toto. Recenzia je vec, ktorá vás spomaľuje. Vo všeobecnosti to má svoje výhody, ale musíte pochopiť, prečo to robíte. Je to spôsob, ako rýchlo sprostredkovať informácie, je to spôsob, ako si interne nastaviť nejaké štandardy alebo čo? Prečo to potrebujete? Pretože revíziu treba urobiť buď veľmi rýchlo, alebo ju úplne zrušiť. Je to ako transbase vývoj - príbeh je veľmi krásny, ale len pre zrelých chlapov.
Pokiaľ ide o 4 metriky, stále by som ich odporúčal odstrániť, aby ste pochopili, k čomu to vedie. Pozrite sa na čísla, pozrite sa na obrázok, aké zlé je všetko.
(Dmitrij) Som pripravený vstúpiť s vami o tom do diskusie. Čísla a metriky sú skvelé, praktiky sú skvelé. Musíte však pochopiť, či to podnik potrebuje. Sú firmy, ktoré takúto rýchlosť zmien nepotrebujú. Poznám firmy, kde sa zmeny nedajú robiť každých 15 minút. A nie preto, že sú také zlé. Toto je taký životný cyklus. A na to, aby fungovali pobočky, funkcia prepínania, potrebujete hlboké znalosti.
Je to komplikované. Ak si chcete prečítať príbeh o funkcii prepínania podrobnejšie, vrelo to odporúčam . A je tu úžasný článok od Martina Fowlera o funkciách prepínania: aké typy existujú, životné cykly atď. Funkcia prepínania je komplikovaná.
A stále ste neodpovedali na otázku: "Je Jenkins potrebný alebo nie?"
Jenkins v žiadnom prípade naozaj netreba. Ale vážne, nástroje: Jenkins, Gitlab vám prinesú pohodlie. Uvidíte, či je zostava zmontovaná alebo nezmontovaná. Môžu vám pomôcť, ale nedajú vám prax. Môžu vám dať iba kruh - Ok, nie Ok. A potom, ak píšeš aj testy, lebo ak testy nie sú, tak je to takmer zbytočné. Preto je to potrebné, pretože je to pohodlnejšie, ale vo všeobecnosti môžete žiť bez toho, nestratíte veľa.
To znamená, že ak máte praktiky, znamená to, že to nepotrebujete?
To je správne. Odporúčam test Jez Humble. Tam mám k poslednému bodu ambivalentný postoj. Ale vo všeobecnosti, ak máte tri veci, neustále sa zlučujete, spúšťate testy odovzdania v hlavnom počítači, rýchlo opravíte zostavu v hlavnom počítači, potom možno nepotrebujete nič iné.
Kým čakáme na otázky účastníkov, mám otázku. Hovorili sme len o kóde produktu. Použili ste ho pre kód infraštruktúry? Je to ten istý kód, má rovnaké princípy a rovnaký životný cyklus, alebo existujú rôzne životné cykly a princípy? Zvyčajne, keď každý hovorí o kontinuálnej integrácii a rozvoji, každý zabudne, že existuje aj kódex infraštruktúry. A v poslednej dobe je toho stále viac. A mali by sa tam vniesť všetky tieto pravidlá?
Ani nie, že by to tak malo byť, bolo by to skvelé, pretože by to uľahčilo život rovnakým spôsobom. Akonáhle pracujeme s kódom, nie s bash skriptami, ale máme normálny kód.
Stop, stop, bash skript je tiež kód. Nedotýkaj sa mojej starej lásky.
Dobre, nebudem šliapať po tvojich spomienkach. Osobne nemám rád bash. Po celý čas sa to škaredo a desivo láme. A často sa nepredvídateľne pokazí, a preto sa mi to nepáči. Ale dobre, povedzme, že máte bash kód. Možno tomu naozaj nerozumiem a existujú normálne testovacie rámce. Len sa v tom nevyznám. A získame rovnaké výhody.
Hneď ako pracujeme s infraštruktúrou ako s kódom, dostávame rovnaké problémy ako vývojári. Pred pár mesiacmi som sa stretol so situáciou, keď mi kolega poslal požiadavku na stiahnutie 1 000 riadkov v bash. A 4 hodiny sedíte pri recenzii. Vznikajú rovnaké problémy. Stále je to kód. A stále je to spolupráca. Zasekneme sa pri požiadavke na stiahnutie a zasekneme sa pri tom, že napríklad riešime rovnaké konflikty zlučovania v rovnakom bashu.
Teraz sa veľmi aktívne pozerám na toto celé na najkrajšie infra programovanie. Teraz som priviedol Pulumi do infraštruktúry. Toto je programovanie vo svojej najčistejšej forme. Tam je to ešte krajšie, pretože mám všetky možnosti programovacieho jazyka, t.j. urobil som z ničoho nič krásny prepínač s rovnakými if a všetko je v poriadku. To znamená, že moja zmena je už v pánovi. Každý ho už vidí. Iní inžinieri o tom vedia svoje. Už to tam niečo ovplyvnilo. Nebolo to však povolené pre všetky infraštruktúry. Napríklad sa mi zapol na skúšobných laviciach. Preto, aby som znova odpovedal na vašu otázku, je potrebné. Rovnakým spôsobom nám ako inžinierom pracujúcim s kódom uľahčuje život.
Ak má niekto ďalšie otázky?
Mám otázku. Chcem pokračovať v diskusii s Olegom. Vo všeobecnosti si myslím, že máš pravdu, že ak nejaká úloha trvá mesiac, tak máš problém s architektúrou, máš problém s analýzou, rozkladom, plánovaním atď. Ale mám pocit, že ak začneš snažte sa žiť podľa kontinuálnej integrácie, potom začnete bolesť korigovať plánovaním, pretože inde sa od nej nedostanete.
(Oleg) Áno, je to tak. Táto prax je v úsilí porovnateľná s akoukoľvek inou serióznou praxou meniacou kultúru. Najťažšie sa prekonávajú návyky, najmä zlozvyky. A ak je na implementáciu tejto praxe potrebná vážna zmena návykov ľudí okolo vás: vývojári, manažment, vedúci výroby, potom na vás čakajú prekvapenia.
Aké prekvapenia môžu byť? Povedzme, že sa rozhodnete, že sa budete integrovať častejšie. A máte nejaké ďalšie veci spojené s integráciou, napríklad artefakty. A vo vašej firme napríklad platí zásada, že každý artefakt musí byť nejakým spôsobom zaúčtovaný v nejakom systéme uloženia artefaktov. A to nejaký čas trvá. Osoba musí začiarknuť políčko, že ako správca vydania otestoval tento artefakt, aby sa uistil, že je pripravený na vydanie v produkcii. Ak to trvá 5-10-15 minút, ale rozloženie robíte raz týždenne, potom je polhodina raz týždenne malá daň.
Ak robíte nepretržitú integráciu 10-krát denne, potom je potrebné 10-krát vynásobiť 30 minútami. A to presahuje množstvo pracovného času tohto manažéra vydania. Len ho to unavuje. Niektoré praktiky majú fixné náklady. To je všetko.
A toto pravidlo musíte buď zrušiť, aby ste už nerobili takéto odpadky, teda ručne nepriraďujete stupeň, ktorý má niečomu zodpovedať. Úplne sa spoliehate na nejaký automatizovaný súbor testov pripravenosti.
A ak potrebujete od niekoho dôkaz, aby to šéf podpísal, a vy sa nedostanete do výroby bez toho, aby Vasya povedal, že to povoľuje atď. - všetky tieto nezmysly prekážajú praktizujúcim. Pretože ak sú nejaké činnosti spojené s daňou, tak sa všetko 100-násobne zvyšuje. Preto posun často neprivítajú všetci s radosťou. Pretože návyky ľudí sa ťažko menia.
Keď človek robí svoju bežnú prácu, robí ju takmer bez rozmýšľania. Jej kognitívna záťaž je nulová. Len sa s tým hrá, už má v hlave kontrolný zoznam, urobil to tisíckrát. A akonáhle prídete a poviete mu: „Zrušme túto prax a od pondelka zaveďme novú,“ pre neho sa to stane silnou kognitívnou záťažou. A príde na každého naraz.
Preto najjednoduchšia vec, aj keď nie každý si môže dovoliť tento luxus, ale to je to, čo vždy robím, je to nasledovné. Ak sa rozbehne nový projekt, tak sa väčšinou všetky neodskúšané praktiky okamžite napchajú do tohto projektu. Aj keď je projekt mladý, naozaj nič neriskujeme. Zatiaľ tu nie je Prod, nie je čo ničiť. Preto sa dá použiť ako tréning. Tento prístup funguje. Ale nie všetky spoločnosti majú možnosť často rozbiehať takéto projekty. Aj keď je to tiež trochu zvláštne, pretože teraz prebieha úplná digitálna transformácia, každý musí začať experimentovať, aby udržal krok s konkurenciou.
Tu prichádzate k záveru, že najprv musíte pochopiť, čo musíte urobiť. Svet nie je ideálny a ani produkt nie je ideálny.
Áno, tieto veci sú vzájomne prepojené.
Firmy tiež nie vždy chápu, že musia ísť touto cestou.
Existuje situácia, v ktorej nie sú možné žiadne zmeny. To je situácia, keď je na mužstvo väčší tlak. Mužstvo je už dosť vyhorené. Nemá čas na žiadne experimenty. Na funkciách pracujú od rána do večera. A manažment má stále menej funkcií. Vyžaduje sa stále viac a viac. V takejto situácii nie sú možné žiadne zmeny. Tímu možno len povedať, že zajtra urobíme to isté ako včera, len musíme urobiť trochu viac funkcií. V tomto zmysle nie sú možné žiadne prechody na akékoľvek praktiky. Ide o klasickú situáciu, keď nie je čas na brúsenie sekery, treba rúbať stromy, tak ju sekajú tupou sekerou. Neexistujú žiadne jednoduché tipy.
(Dmitry) Prečítam si vysvetlenie z rozhovoru: „Potrebujeme však veľa testov na rôznych úrovniach. Koľko času je vyčlenených na testy? Je to trochu drahé a zaberie to veľa času."
(Oleg) Toto je klasická mylná predstava. Testov by malo byť dosť, aby ste si boli istí. Nepretržitá integrácia nie je vec, pri ktorej sa najskôr vykoná 100 % testov a až potom začnete uplatňovať túto prax. Nepretržitá integrácia znižuje vašu kognitívnu záťaž vďaka tomu, že každá zo zmien, ktoré vidíte očami, je taká zrejmá, že aj bez testov pochopíte, či niečo pokazí alebo nie. Môžete si to rýchlo otestovať v hlave, pretože zmeny sú malé. Aj keď máte iba manuálne testery, je to pre nich jednoduchšie. Vyvalili ste sa a povedali ste: "Pozri, je niečo zlomené?" Skontrolovali a povedali: "Nie, nič nie je zlomené." Pretože tester vie, kde má hľadať. Máte jedno potvrdenie spojené s jedným kúskom kódu. A to sa využíva špecifickým správaním.
Tu si, samozrejme, prikrášlil.
(Dmitry) Tu nesúhlasím. Existuje prax - testom riadený vývoj, ktorý vás od toho ušetrí.
(Oleg) No, k tomuto bodu som sa ešte nedostal. Prvou ilúziou je, že musíte napísať 100 % testov alebo vôbec nemusíte robiť nepretržitú integráciu. Nie je to pravda. Ide o dve paralelné praktiky. A nie sú priamo závislé. Vaše testovacie pokrytie by malo byť optimálne. Optimálne - to znamená, že vy sami ste si istí, že kvalita majstra, v ktorom váš majster zostal po odovzdaní, vám umožňuje s istotou stlačiť tlačidlo „Nasadiť“ v opitý piatok večer. Ako to dosiahnete? Cez kontrolu, cez pokrytie, cez dobrý monitoring.
Dobrý monitoring je na nerozoznanie od testov. Ak raz spustíte testy na predprodukcii, potom raz skontrolujú všetky vaše používateľské skripty a to je všetko. A ak ich spúšťate v nekonečnej slučke, tak toto je váš nasadený monitorovací systém, ktorý donekonečna testuje všetko – či spadol alebo nie. V tomto prípade je rozdiel len v tom, či sa to robí raz alebo dvakrát. Veľmi dobrý súbor testov... bežiacich donekonečna, toto je monitorovanie. A správne monitorovanie by malo byť takéto.
A preto, ako presne tento stav dosiahnete, keď sa v piatok večer pripravíte a pôjdete domov, je iná otázka. Možno si len smelý srab.
Vráťme sa trochu k kontinuálnej integrácii. Utiekli sme do trochu inej zložitej praxe.
A druhá ilúzia je, že MVP vraj treba urobiť rýchlo, takže tam testy vôbec netreba. Takýmto spôsobom určite nie. Faktom je, že keď napíšete používateľský príbeh do MVP, môžete ho buď rozvinúť na loptičku, to znamená, že ste počuli, že existuje nejaký používateľský príbeh, a okamžite ste ho bežali kódovať, alebo môžete pracovať pomocou TDD. A podľa TDD, ako ukazuje prax, to netrvá dlhšie, t.j. testy sú vedľajším účinkom. Prax TDD nie je o testovaní. Napriek tomu, čo sa nazýva Test Driven Development, vôbec nejde o testy. Toto je tiež skôr architektonický prístup. Toto je prístup, ako písať presne to, čo je potrebné, a nepísať to, čo nie je potrebné. Toto je prax zamerania sa na ďalšiu iteráciu vášho myslenia z hľadiska vytvárania aplikačnej architektúry.
Preto nie je také ľahké zbaviť sa týchto ilúzií. MVP a testy si neprotirečia. Dokonca, skôr naopak, ak robíte MVP pomocou cvičenia TDD, tak to urobíte lepšie a rýchlejšie, ako keby ste to robili úplne bez cvičenia, ale na lopte.
Toto je veľmi nejasná a zložitá myšlienka. Keď počujete, že teraz budem písať ďalšie testy a zároveň niečo rýchlejšie urobím, znie to absolútne neadekvátne.
(Dmitry) Veľa ľudí tu, keď volajú MVP, sú príliš leniví na to, aby napísali niečo normálne. A to sú stále iné veci. Nie je potrebné zmeniť MVP na nejakú zlú vec, ktorá nefunguje.
Áno, áno, máš pravdu.
A potom zrazu MVP v prod.
Navždy.
A TDD znie veľmi nezvyčajne, keď počujete, že píšete testy a zdá sa, že robíte viac práce. Znie to veľmi zvláštne, ale v skutočnosti to takto vyzerá rýchlejšie a krajšie. Keď píšete test, v hlave už veľa premýšľate o tom, aký kód sa bude volať a ako, a tiež aké správanie od neho očakávame. Nehovoríte, že som napísal nejakú funkciu a tá niečo robí. Najprv ste si mysleli, že má také a onaké stavy, bude ju volať tak a tak. Pokryjete to testami a z toho pochopíte, ako budú vaše rozhrania vyzerať vo vašom kóde. To má obrovský vplyv na architektúru. Váš kód sa automaticky stane modulárnejším, pretože sa najprv pokúsite pochopiť, ako ho budete testovať, a až potom ho napíšete.
S TDD sa mi stalo, že v určitom bode som si najal mentora Ruby, keď som bol ešte programátorom Ruby. A hovorí: "Urobme to podľa TDD." Pomyslel som si: "Sakra, teraz musím napísať niečo navyše." A dohodli sme sa, že do dvoch týždňov napíšem všetok pracovný kód v Pythone pomocou TDD. Po dvoch týždňoch som si uvedomil, že sa nechcem vrátiť. Po dvoch týždňoch, keď sa to snažíte aplikovať všade, si uvedomíte, ako je pre vás jednoduchšie čo i len myslieť. Ale to nie je samozrejmé, preto každému odporúčam, ak máte pocit, že TDD je ťažké, časovo náročné a zbytočné, skúste to vydržať len dva týždne. Dva mi stačili.
(Dmitry) Túto myšlienku môžeme rozšíriť z pohľadu prevádzky infraštruktúry. Predtým, ako spustíme niečo nové, vykonáme monitorovanie a potom spustíme. V tomto prípade sa pre nás monitorovanie stáva bežným testovaním. A je tu vývoj prostredníctvom monitorovania. Ale takmer každý hovorí, že je to dlhé, som lenivý, urobil som dočasný koncept. Ak sme vykonali bežné monitorovanie, rozumieme stavu systému CI. A systém CI má veľa monitorovania. Chápeme stav systému, chápeme, čo je v ňom. A pri vývoji už len robíme systém tak, aby sa dostal do želaného stavu.
Tieto praktiky sú známe už dlho. Diskutovali sme o tom asi pred 4 rokmi. Ale za 4 roky sa prakticky nič nezmenilo.
V tejto súvislosti však navrhujem ukončiť oficiálnu diskusiu.
Video (vložené ako mediálny prvok, ale z nejakého dôvodu nefunguje):
Zdroj: hab.com