Beszéljünk arról, hogy miért különböznek a CI-eszközök és a CI teljesen.
Milyen problémát old meg a CI, honnan jött az ötlet, mik az utolsó megerősítések, hogy működik, hogyan érthetjük meg, hogy valóban gyakorlatunk van, nem csak egy telepített Jenkins.
Az ötlet, hogy előadást tartsak a folyamatos integrációról, már egy éve megszületett, amikor állásinterjúkra jártam. 10-15 céggel beszélgettem, és csak egy tudta érthetően elmagyarázni, mi a CI, és hogy miként jutottak arra, hogy nekik ez nincs. A többiek pedig zavaros hülyeségeket mondtak Jenkinsről 🙂 Nos, van Jenkins, csinálja a buildet, ami CI! Az előadásomban igyekszem magyarázni, mi is a folyamatos integráció valójában, és miért van ez a nagyon gyenge viszonya Jenkinsnek és hasonló eszközöknek.
Szóval, mi jut általában eszünkbe a CI szónál? A legtöbb embernek a Jenkins, Gitlab CI, Travis stb. jut eszébe.
Még ha rákeresünk, is ezeket az eszközöket fogjuk kapni.
Ha megkérdezzük, hogy ismerik-e, akkor a felsorolás után azonnal elmondják, hogy a CI az, amikor a Pull Request alatt a commitnál build történik és tesztek futnak.
A folyamatos integráció nem az eszközökről szól, nem a buildről a tesztekkel az ágon! A folyamatos integráció a következő kód nagyon gyakori integrálásáról szól, és ennek megvalósításához nem szükséges Jenkinseket, GitLabokat és hasonlókat építeni.
Mielőtt áttekintenénk, hogy néz ki a teljes értékű CI, először merüljünk el azoknak az embereknek a kontextusában, akik ezt kitalálták, és érezzük át azt a fájdalmát, amit megpróbáltak megoldani.
Azt a fájdalmat oldották meg, ami a csapatban történő együttműködésből fakadt!
Nézzük meg példákon, milyen nehézségekkel néznek szembe a fejlesztők csapatban történő fejlesztéskor. Van egy projektünk, a master-ág a gitben, és két fejlesztő.
Elkezdték dolgozni, mint ahogy azt régóta megszokták. Felvettek egy feladatot a JIRA-ban, létrehoztak egy feature branchet, és írták a kódot.
Az egyikük gyorsabban befejezte a funkciót, és összeolvadt a masterrel.
A másiknak több időre volt szüksége, később olvadt össze, és konfliktust kapott. Most ahelyett, hogy szükséges üzleti funkciókat írna, a fejlesztő az idejét és energiáját konfliktusok megoldására fordítja.
Minél nehezebb összekapcsolni a funkciódat a közös főágával, annál több időt pazarolunk el rá. És ez még egy viszonylag egyszerű példa. Ez egy példa, ahol csak 2 fejlesztő van. De képzeld el, ha 10 vagy 15 vagy 100 ember ír ugyanabba a tárolóba. Megőrülnél az összes konfliktus megoldásától.
Van egy kis eltérő eset. Van egy főágunk és néhány fejlesztő, akik dolgoznak valamin.
Mindegyikük létrehozott egy ágat.
Az egyik összeolvadt, minden rendben van, befejezte a feladatát.
A második fejlesztő időközben befejezte a feladatát. Tegyük fel, hogy elküldte felülvizsgálatra. Sok cégnél van egy ilyen gyakorlat – a felülvizsgálat. Egyrészt ez egy jó és hasznos gyakorlat, másrészt viszont sok helyen lelassít minket. Nem merüljünk bele, de itt egy remek példa arra, hova vezethet a hibás felülvizsgálati folyamat. Elküldted a pull requestet felülvizsgálatra. A fejlesztőnek nincs más dolga. Mit kezd el csinálni? Elkezd más feladatokat hozni.
Ez idő alatt a második fejlesztő is dolgozott valamin.
Az első befejezte a harmadik feladatát.
És egy bizonyos idő elteltével, amikor a felülvizsgálata megtörtént, próbálkozik az összevonással. És mi történik? Hatalmas mennyiségű konfliktust fog elkapni. Miért? Mert míg a pull requestje felülvizsgálatra várt, a kódban már sok minden megváltozott.
A konfliktusok története mellett van egy másik történet a kommunikációval. Amíg a te ágad felülvizsgálatra vár, miközben hosszú ideig dolgozol a funkción, abbahagyod annak követését, hogy mi változik még a szolgáltatásod kódalapjában. Lehet, hogy amit most próbálsz megoldani, azt már tegnap megoldották, és újra felhasználhatsz egy módszert. De ezt nem látod, mert mindig egy elavult ággal dolgozol. És ez az elavult ág mindig ahhoz vezet, hogy mergen konfliktust kell megoldanod.
Tehát, ha csapatban dolgozunk, tehát nem egy ember turkál a tárolóban, hanem 5-10 ember, akkor minél tovább nem adjuk hozzá a kódunkat a főághoz, annál inkább szenvedünk attól, hogy végül össze kell vonnunk valamit. Minél több konfliktusunk van, és minél régebbi verzióval dolgozunk, annál több problémánk lesz.
Közösen dolgozni – ez fájdalmas! Mindig zavarjuk egymást.
Erre a problémára több mint 20 évvel ezelőtt irányították a figyelmet. Az első említést a Continuous Integration gyakorlatáról az Extreme Programmingben találtam.
Az Extreme Programming az első agilis keretrendszer. Az oldal 1996-ban készült el. Az ötlet az volt, hogy különböző programozási, tervezési és egyéb gyakorlatokat alkalmazzunk annak érdekében, hogy a fejlesztés a lehető legnagyobb rugalmassággal működjön, így gyorsabban reagálhatunk a változásokra és az ügyfeleink igényeire. 24 évvel ezelőtt kezdték ezzel szembesülni, hogy ha valamit nagyon sokáig és egyedül csinálsz, akkor több időt pazarolsz rá, mert összeütközések keletkeznek.
Most a „Continuous Integration” kifejezés jelentését bontjuk le a szavakra. Ha szó szerint fordítjuk, akkor folyamatos integrációt kapunk. De hogy mennyire folyamatos, az nem teljesen világos, valójában nagyon is megszakított. Az is megkérdőjelezhető, hogy mennyire integráció a bővítmény.
Ezért most idézeteket idézek az Extreme Programmingből. Mindkét szót külön fogjuk elemezni.
Integráció — Ahogy már mondtam, arra törekszünk, hogy minden mérnök a legfrissebb kódkapcsolattal dolgozzon, és a saját kódját a lehető leggyakrabban adja hozzá a közös ághoz, hogy ezek kicsi ágacskák legyenek. Mert ha nagyok, akkor könnyen egy hétig akadozhatunk a merge konfliktusok miatt. Különösen, ha hosszú fejlesztési ciklusunk van, mint a waterfall, ahol a fejlesztő egy hónapig dolgozik egy hatalmas funkción. Az integráció szakaszában nagyon sokáig akadhat.
Az integráció — amikor a saját ágat összevonjuk a mester ággal, akkor merge-eljük. Van egy végső megoldás, amikor transbase developert alkalmazunk, ahol törekszünk arra, hogy közvetlenül a mesterbe írjunk, felesleges ágak nélkül.
Összefoglalva, az integráció azt jelenti, hogy a saját kódodat átvisszük a mester ágba.
Mit értenek itt a „folyamatos” szó alatt, mi nevezhető folyamatosságnak? A gyakorlat azt jelenti, hogy a fejlesztő arra törekszik, hogy a kódját a lehető leggyorsabban integrálja. Ez a célja bármilyen feladat elvégzésekor – hogy a kódja minél hamarabb bekerüljön a mesterségbe. Ideális világban a fejlesztők ezt pár óránként tennék. Tehát, veszel egy kis feladatot, és összemergíted a mesterséggel. Minden csodálatos. Tehát erre törekszel. Ezt folyamatosan kell csinálni. Amint befejeztél valamit, azonnal be is rakod a mestersébe.
A fejlesztő, aki valamit csinál, felelősséggel tartozik azért, amit tett, hogy az működjön és ne törjön el semmit. Itt jön elő általában a tesztelés története. Szeretnénk néhány tesztet futtatni a commitunkra, az összemergerünkre, hogy megbizonyosodjunk róla, hogy működik. És itt segíthetnek neked a Jenkins.
De a történetek mind arról szólnak, hogy a változások kicsik legyenek, a feladatok kicsik legyenek, és hogy megoldjuk a feladatot, majd azonnal megpróbáljuk összemergíteni a mestersébe – itt a Jenkins sem segít. Mert a Jenkins kizárólag a tesztek futtatásában segít.
Meg is lehet nélküle oldani. Ez nem okoz problémát. Mert a gyakorlat célja, hogy minél gyakrabban összemerjük, hogy ne pazaroljunk el óriási mennyiségű időt jövőbeli konfliktusokra.
Képzeljük el, hogy 2020-ban valamiért nincs internet. Helyben dolgozunk. Nincs Jenkinsünk. Ez rendben van. Még mindig létrehozhatsz egy helyi ágat. Írtál valamilyen kódot benne. Megcsináltál egy feladatot 3-4 óra alatt. Átv switched a mesterségre, végeztél egy git pull-t, és mergesd az ágad. Kész. Ha ezt gyakran csinálod – gratulálok, neked van Folyamatos Integrációd!
Mik a mai világban a bizonyítékok arra, hogy érdemes erre az energiát fordítani? Mert ez összességében nehéz. Ha így próbálsz dolgozni, meg fogod érteni, hogy mostanában valamiféle tervezésben kihatásaid lesznek, több időt kell szentelned a feladatok dekomponálására. Mert ha csinálod a man…-t, akkor nem tudsz gyorsan összemergetni, és ennek megfelelően kellemetlen helyzetbe fogsz kerülni. Gyakorlatod már nem lesz.
Ez drága lesz. A Continuous Integration-nel holnaptól dolgozni nem fogunk tudni. Mindannyian nagyon sokáig fogtok hozzászokni, nagyon sokáig fogtok tanulni a feladatok lebontására, nagyon sokáig fogtok tanulni a review gyakorlatait, ha van ilyen. Mert a mi célunk, hogy a ma össze legyen fésülve. Ha pedig a review-t három nap alatt csináljátok, akkor problémáitok lesznek, és a Continuous Integration nem fog működni.
De vannak aktuális bizonyítékaink, amik éppen most mondják nekünk, hogy érdemes ebbe a gyakorlatba fektetni?
Az első, ami eszembe jutott – a State of DevOps. Ez egy kutatás, amit a fiúk már 7 éve végeznek. Most már független szervezetként csinálják, de a Google alatt.
Az ő 2018-as kutatásuk korrelációt mutatott a cégek között, amelyek próbálnak rövid életű ágakat használni, amelyek gyorsan, gyakran integrálódnak, sokkal szebb IT teljesítmény mutatókkal rendelkeznek.
Mik ezek a mutatók? Ez 4 mérőszám, amelyeket minden cégtől gyűjtenek a kérdőíveikben: telepítési gyakoriság, a változásokhoz szükséges idő, a szolgáltatás helyreállításához szükséges idő, a változások hibás aránya.
Először is, van ez a korreláció, tudjuk, hogy a cégek, amelyek gyakran összeolvadnak, sokkal jobban teljesítenek ezekben a mutatókban. És a cégeket több kategóriába bontják: lassú cégek, amelyek lassan termelnek, közepes teljesítményűek, magas teljesítményűek és az elit. Az elit – ez a Netflix, az Amazon, akik szupergyorsak, mindent gyorsan, szépen és minőségben csinálnak.
A második történet, ami éppen egy hónappal ezelőtt történt. A Technology Radar-ban megjelent egy nagyszerű jegyzet a Gitflow-ról. A Gitflow abban különbözik az összes többitől, hogy az ágai sokáig élnek. Vannak kiadási ágak, amelyek sokáig élnek, feature ágak, amelyek szintén sokáig élnek. Ez a gyakorlat a Technology Radar-ban a HOLD-ba került. Miért? Mert az emberek szembesülnek az integrációs fájdalmakkal.
Ha az ág nagyon sokáig él, akkor elakad, megromlik, és elkezdünk több időt pazarolni arra, hogy valamilyen változást vigyünk bele.
Nemrégiben a Gitflow szerzője azt mondta, hogy ha a folyamatos integrációra törekszik, és azt szeretné, hogy a lehető leggyakrabban bejusson, akkor a Gitflow rossz ötlet. Külön írt egy cikkben arról, hogy ha van backendje, ahol ezt célul tűzheti ki, akkor a Gitflow felesleges, mert az lassítani fogja, és problémákat okoz az integrációval.
Ez nem jelenti azt, hogy a Gitflow rossz, és hogy nem kell használnia. Más esetekre való. Például, amikor több verziót kell fenntartania a szolgáltatásból vagy alkalmazásból, azaz amikor hosszabb időn át kell támogatnia.
De ha beszélget a szolgáltatásokat támogató emberekkel, sok fájdalmat hall, hogy ez a verzió 3.2 volt, ami négy hónappal ezelőtt készült, és ebbe nem került be ez a javítás, és most, hogy ezt be lehessen vinni, rengeteg módosítást kell végezni. És megint elakadnak, és hetekig dolgoznak azon, hogy be tudjanak illeszteni egy új funkciót.
Ahogy Alexander Kovalev helyesen megjegyezte a csoportban, a korreláció nem egyenlő az ok-okozati összefüggéssel. Így van. Azaz nincs közvetlen összefüggés, hogy ha van folyamatos integráció, akkor minden mutató csodálatos lesz, nem. De van pozitív korreláció, hogy ha az egyik, akkor valószínűleg a másik is az. Nem biztos, de valószínű. Ez csupán egy korreláció.
Úgy tűnik, hogy már csinálunk valamit, úgy tűnik, hogy már össze is olvadunk, de hogyan tudjuk meg, hogy a folyamatos integráció valóban megvan, hogy elég gyakran olvadunk össze?
Jez Humble a Handbook, az Accelerate, a Continuous Delivery webhely és a "Continuous Delivery" könyv szerzője. Ő egy ilyen tesztet javasol:
- A mérnök kódja naponta kerül be a master branchbe.
- Minden egyes commitnál egységteszteket futtat.
- A masterben lévő build megbukott, körülbelül 10 percen belül javították.
Azt javasolja, hogy használja ezt a tesztet, hogy megbizonyosodjon arról, hogy a gyakorlat biztosan jelen van.
Az utolsót kicsit vitásnak találom. Tehát, ha 10 perc alatt tudjátok javítani, akkor van Continuous Integration, ez kicsit furcsán hangzik a véleményem szerint, de van benne logika. Miért? Mert ha gyakran egyesítetek, az azt jelenti, hogy a változások kicsiek. Ha egy apró változás miatt megszakad a master build, gyorsan megtaláljátok az okát, mert a változás kicsi. Volt egy apró egyesítés, amelyben 20-30 sor módosult. Ennek megfelelően gyorsan megérthetitek, hogy mi volt a probléma oka, mert a változások aprók, tehát nagyon kicsi a hiba keresési területe.
És még ha a kiadás után a prod szétesik is, ha van Continuous Integration gyakorlatunk, sokkal könnyebb cselekedni, mert a változások aprók. Igen, ez érinteni fogja a tervezést. Fájni fog. És valószínűleg a legnehezebb e gyakorlatban az, hogy megszokjátok, hogyan kell apró feladatokat végezni, tehát hogyan lehet valamit megcsinálni néhány óra alatt, és mellette átmenni a felülvizsgálaton, ha van. A felülvizsgálat – ez egy külön fájdalom.
A unit tesztek csak segítők, amelyek segítenek megérteni, hogy valóban sikeres volt-e az integráció, valóban semmi nem romlott el. Véleményem szerint ez sem kötelező elem, mert a gyakorlat lényege nem ez.
Ez röviden a Continuous Integration. Ez minden, ami ebben a gyakorlatban szerepel. Készen állok a kérdésekre.
Röviden összefoglalva még egyszer:
- A Continuous Integration nem Jenkins, ez nem GitLab.
- Ez nem eszköz, hanem arról szól, hogy a lehető legtöbbször egyesítjük a kódunkat a master-be.
- Ezt azért csináljuk, hogy elkerüljük a jövőbeli óriási fájdalmakat, tehát most kicsi fájdalmat érzünk, hogy a jövőben elkerüljünk egy nagyot. Ebben rejlik az egész lényeg.
- A kódon keresztül kommunikáció folyik, de ezt ritkán látom, de ezért is tervezték.
Kérdések
Mit tegyünk a nem dekomponálható feladatokkal?
Dekomponálni. Mi a probléma? Tudnál példát hozni, hogy van egy feladat, és az nem dekomponálható?
Vannak olyan feladatok, amelyeket egyáltalán nem lehet dekomponálni, például azok, amelyek nagyon mély szakértelmet igényelnek, és amelyeket valóban hónapokig lehet megoldani egy elviselhető eredményhez.
Ha jól értelek, van egy nagy és komplex feladat, aminek az eredménye csak egy hónap múlva lesz látható?
Igen, pontosan. Igen, az eredményt legkorábban egy hónap múlva lehet értékelni.
Jól van. Összességében ez nem probléma. Miért? Mert ebben az esetben, amikor az ágakról beszélünk, nem egy olyan ágról beszélünk, amely benne van a funkcióval. A funkciók lehetnek nagyok és összetettek. Sok komponenst érinthetnek. És lehet, hogy nem tudjuk egy ágon teljesen megvalósítani őket. Ez normális. Csak ezt a történetet kell szétbontanunk. Ha a funkció nem kész teljesen, az nem jelenti azt, hogy a kódja egyes részei nem mergethetők. Például hozzáadtál egy migrációt, és a funkcióban vannak bizonyos lépések. Például van egy lépés – a migráció elkészítése, új metódus hozzáadása. Ezeket a dolgokat már napi rendszerességgel merge-elheted.
Rendben. Mi értelme van ennek?
Mi értelme van kicsi dolgokat napi szinten merge-elni?
Igen.
Ha valami elromlott, azt azonnal látod. Van egy kis darab, ami elromlott, és könnyebb azt javítani. Az értelme az, hogy egy kis darab most sokkal könnyebb merge-elni, mint egy nagyot néhány hét múlva. A harmadik értelme pedig az, hogy más mérnökök már a legfrissebb kódverzióval fognak dolgozni. Látni fogják, hogy itt néhány migráció hozzá lett adva, ott megjelent egy új metódus, amit szintén lehet, hogy használni akarnak. Mindenki látni fogja, hogy mi történik a kódban. Pontosan ezek miatt a három dolog miatt van ennek a gyakorlatnak értelme.
Köszönöm, a kérdés lezárva!
(Oleg Soroka) Hozzátehetek valamit? Jól mondtad, csak egy mondatot szeretnék hozzáfűzni.
Igen.
A Continuous Integration keretében a kód a közös ágba nem akkor merge-elődik, amikor a funkció teljesen kész, hanem amikor a build már nem hibázik. És bátran commitálhatsz a masterbe, ahányszor csak akarod naponta. A második szempont – ha valami okból nem tudod a havi feladatot legalább háromnapos feladatokra bontani, nem beszélve a háromórásakról, akkor hatalmas problémád van. És az a tény, hogy nincs Continuous Integration – ez a legkisebb ezek közül a problémák közül. Ez azt jelenti, hogy problémáid vannak az architektúrával, és az mérnöki gyakorlatod a nullán van. Mert ha ez még kutatás is, akkor is meg kell jeleníteni hipotézisek vagy ciklusok formájában.
Beszéltünk négy olyan metrikáról, amelyek megkülönböztetik a sikeres vállalatokat a lemaradóktól. Ezeket a négy metrikát előbb még el kell érni. Ha egy átlagos feladat elvégzése egy hónapba telik, akkor először erre a metrikára kellene összpontosítani. Ezt előbb három napra kellene csökkenteni, és csak azután érdemes a Continuous-ra gondolni.
Jól értettem, hogy azt gondolod, hogy általánosságban nincs értelme befektetni a mérnöki gyakorlatokba, ha bármely feladat egy hónapig tart?
Van Continuous Integration-ed. Ott van az a téma, hogy húsz perc alatt vagy megjavítod a hibát, vagy visszavonod. Képzeld el, hogy kiadtad. Ráadásul van folyamatos kiadásod, kiadtad a produkcióra, és csak utána vetted észre, hogy valami nem ment jól. Vissza kell vonnod, de már megtörtént az adatbázis-migráció. Már a következő verziójú adatbázis séma van, sőt, még egy adatbázis mentés is történt, és már adatok is kerültek oda.
Mi a lehetőséged? Ha visszavonod a kódot, már nem tud kapcsolódni ehhez az új, frissített adatbázishoz.
Az adatbázis csak előre halad, igen.
Azok az emberek, akiknél rossz mérnöki gyakorlat van, valószínűleg nem is olvasták el azt a vastag könyvet ... Mi a helyzet a mentéssel? Ha egy mentésből állsz helyre, akkor elveszíted az abban az időszakban megszerzett adatokat. Például dolgoztál három órát az új verziójú adatbázissal, ott regisztráltak felhasználók. Te a régi mentésre állsz vissza, mert az új verziójú séma nem működik, ezért ezeket a felhasználókat elvesztetted. Ráadásul ők elégedetlenek, és panaszkodnak.
Ahhoz, hogy elsajátítsd a folyamatos integrációt és folyamatos szállítást támogató összes gyakorlatot, nem elég csak annyit megtanulni, hogy .. Az első dolog, hogy ezekből lehet nagyon sok, ami gyakorlatilag használhatatlanná válik. Ráadásul vannak más gyakorlatok is, például a tudományos megközelítés. Éppen ezért népszerűsítette a GitHub egy időben. Ez az, amikor egyszerre fut a régi és az új kód. Amikor egy befejezetlen funkciót készítesz, de ez már visszaadhat valamilyen értéket: akár funkcióként, akár Rest API-ként. Futtatod az új és a régi kódot, és összehasonlítod a kettő közötti különbséget. Ha van eltérés, akkor ezt az eseményt naplózod. Így tudod, hogy az új funkció készen áll a régi helyére való kiadásra, ha bizonyos időn belül nem volt eltérés a kettő között.
Ilyen gyakorlatokból száz van. Én azt javasolnám, hogy kezdj a transbase fejlesztéssel. Ez nem 100%-ig a folyamatos integráción alapul, de a gyakorlatok azonosak, egyik a másik nélkül nem él meg jól.
A transbase fejlesztést hoztad példaként, ahol meg lehet nézni a gyakorlatokat, vagy azt javaslod, hogy az emberek kezdjék el használni a transbase fejlesztést?
Nézni, mivel használni nem tudják. Ahhoz, hogy használni tudják, sok mindent el kell olvasni. És amikor a kérdés felmerül a valakinél: „Mit tegyek a funkcióval, ami egy hónapig tart”, az azt jelenti, hogy nem olvasta el a transbase fejlesztéssel kapcsolatos anyagokat. Én sem ajánlanám ezt most. Azt javaslom, hogy kifejezetten arra összpontosítsanak, hogyan kell helyesen architektúrával felosztani a nagyobb feladatokat kisebb részekre. Ez a dekompozíció lényege.
A dekompozíció az építész egyik eszköze. Először elemzést végzünk, aztán dekompozíciót, majd szintézist, végül integrációt. Így minden összeáll. A folyamatos integrációhoz először dekompozíción kell keresztülmennünk. Az első lépésben felmerülnek kérdések, míg már a negyedik lépésről beszélünk, vagyis minél gyakrabban végezzük az integrációt, annál jobb. Még korai ezt tenni, először inkább a monolitod szétbontásával érdemes foglalkozni.
Néhány nyilat és négyzetet kell rajzolni egy diagramra. Nem mondhatod, hogy most bemutatok egy új alkalmazás architektúráját, és csak egy négyzetet mutatok, amelyben egy zöld gomb van az alkalmazás számára. Minden esetben több négyzet és nyíl lesz. Bármely diagramban, amit láttam, több mint egy volt. A grafikus megjelenítés szintjén történik a dekompozíció is. Tehát a négyzetek függetlenek lehetnek. Ha nem, akkor komoly kérdéseim lennének az architektához.
Van egy kérdés a chatből: „Ha a felülvizsgálat kötelező és sokáig tart, egy napig vagy annál tovább?”
Gondjaid vannak a gyakorlattal. A felülvizsgálatnak nem szabad egy napig vagy tovább tartania. Ez ugyanaz a sztori, mint az előző kérdés, csak kicsit enyhébb. Ha a felülvizsgálat egy napig tart, valószínűleg egy nagyon nagy változtatás felülvizsgálata történik. Ezért kisebbre kellene venni. Az Oleg által ajánlott transbase fejlesztésben van egy történet, amit folyamatos felülvizsgálatnak hívunk. Ennek az a lényege, hogy szándékosan olyan kicsi pull requestet készítünk, mert folyamatosan és kicsit-kicsit szeretnénk egyesülni. Így a pull request egy absztrakciót vagy 10 sort változtat. Ennek köszönhetően a felülvizsgálat pár percet vesz igénybe.
Ha a felülvizsgálat egy napig vagy tovább tart, akkor valami nem stimmel. Először is, lehet, hogy problémáid vannak az architektúrával. Vagy egy nagy kód részletről van szó, mondjuk 1000 sor. Vagy annyira bonyolult az architektúrád, hogy az ember nem tudja megérteni. Ez kicsit mellékszál, de ezt is meg kell oldani. Lehet, hogy egyáltalán nincs szükség felülvizsgálatra. Ezen is el kell gondolkodni. A felülvizsgálat az a dolog, ami lelassít. Összességében vannak előnyei, de tisztázni kell, miért csinálod ezt. Ez gyors információátadás, vagy a belső standardok megállapítása a számodra, vagy mi? Miért van szükséged rá? Mert a felülvizsgálatot nagyon gyorsan kell végezni, vagy teljesen el kell törölni. Ez olyan, mint a transbase fejlesztés – egy nagyon szép történet, de csak érett csapatok számára.
A 4 metrikával kapcsolatban ajánlanám, hogy mindenképpen vegyétek le őket, hogy megértsétek, hova vezet ez. Megnézni a számokat, megnézni a képet, mennyire rossz minden.
(Dmitrij) Készen állok arra, hogy erről a témáról beszélgessek veled. A számok és metrikák klasszak, a praktikák is klasszak. De meg kell érteni, hogy a vállalkozásnak szüksége van-e erre. Vannak vállalkozások, amelyeknek nincs szükségük ilyen gyors változásokra. Ismerek olyan cégeket, ahol 15 percenként nem lehet változtatni. Nem azért, mert rosszak lennének. Ez az életciklus. És ahhoz, hogy a branch funkcióval vagy a toggle funkcióval dolgozzunk, mély ismeretek szükségesek.
Ez nehéz. Ha szeretnél többet olvasni a toggle funkció történetéről, jól ajánlom. . És van egy csodálatos cikk Martin Fowler-tól a toggle funkciókról: arról, hogy milyen típusok léteznek, életciklusok stb. A toggle funkció – ez bonyolult.
De még mindig nem válaszoltál a kérdésre: "A Jenkins szükséges vagy nem szükséges?"
A Jenkins valójában semmilyen esetben nem szükséges. Ha komolyan vesszük, az eszközök: Jenkins, Gitlab kényelmet fognak nyújtani. Látni fogod, hogy a build elkészült-e vagy sem. Segíthetnek neked, de a praktikát nem adják. Csak egy kis kör lesz: Ok, nem Ok. És az is, ha írsz teszteket, mert ha nincsenek tesztek, az majdnem értelmetlen. Tehát szükséges, mert kényelmesebb, de összességében élhetsz nélküle is, nem sokat veszítesz.
Tehát, ha vannak praktikáid, akkor ez azt jelenti, hogy nincs szükséged rá?
Teljesen igaz. Ajánlom a Jez Humble-féle tesztet. Ott van nekem egy vegyes érzésem az utolsó ponttal kapcsolatban. De alapvetően, ha három dolog van: folyamatosan merge-elsz, teszteket futtatsz a master commitjaidon, gyorsan javítod a buildet a masterben, akkor lehet, hogy nem is szükséges más.
Míg várunk a résztvevők kérdéseire, van egy kérdésem. Most a termék kódjáról beszéltünk. Használtad-e infrastruktúra kódra is? Ez ugyanaz a kód, ugyanazok az elvek és ugyanaz az életciklus, vagy ott más életciklusok és elvek vannak? Általában, amikor mindenki a Continuous Integration és Development-ről beszél, elfelejtik, hogy van infrastruktúra kód is. Az utóbbi időben egyre több van belőle. És szükséges-e az összes ezek a szabályokat oda behozni?
Nem arról van szó, hogy szükséges, hanem hogy nagyszerű lenne, mert pontosan így megkönnyítené az életet. Ahogy elkezdünk kóddal dolgozni, nem bash szkriptekkel, hanem normális kóddal.
Állj, állj, a bash szkript is kód. Ne bolygassd a régi szerelmemet.
Rendben, nem fogom taposni az emlékeidet. Személyesen ellenszenvvel vagyok a bash iránt. Csúnyán és félelmetesen törik össze állandóan. Ráadásul gyakran imprédikálisan, ezért nem kedvelem. De rendben, tegyük fel, van egy kódod bashben. Lehet, hogy tényleg nem értek hozzá, és vannak normális tesztelő keretrendszerek is benne. Egyszerűen nem vagyok benne. És ugyanazokat az előnyöket kapjuk.
Amint infrastrukturát dolgozunk kód formájában, ugyanazokkal a problémákkal találkozunk, mint a fejlesztők. Néhány hónappal ezelőtt szembesültem azzal, hogy egy kollégám 1000 soros pull requestet küldött bashben. És te négy órán át elfoglalt vagy a felülvizsgálattal. Ugyanazok a problémák merülnek fel. Ez még mindig kód. És még mindig közös munka. Benne ragadunk a pull requesteknél és a bash mergen ütközések megoldásánál, például.
Mostanában nagyon aktívan figyelem ezt a dolgot a lehető legszebb infrastrukturális programozásban. Jelenleg Pulumi-t hoztam be az infrastruktúrába. Ez tiszta programozás. Itt még szebb, mert szinte ugyanazokat a programozási nyelv lehetőségeit használom, pl. ugyanazzal az if-el gyönyörű toggle-okat készítettem, és minden rendben van. Azaz a változásom már a masterbe került. Mindenki látja. Más mérnökök tudomásul vették. Már hatással volt valamire. De ez nem minden infrastruktúrához kapcsolódik. Például az én tesztkörnyezeteimhez aktiválódott. Ezért válaszolva a kérdésedre, szükséges. Ez nekünk, mint kódot használó mérnököknek, ugyanúgy megkönnyíti az életünket.
Van még valakinek kérdése?
Van egy kérdésem. Szeretném folytatni a vitát Oleggel. Általában azt gondolom, hogy igazad van, ha egy feladat egy hónap alatt készül el, akkor problémád van az architektúrával, részletes elemzéssel, dekompozícióval, tervezéssel stb. De van egy olyan érzésem, hogy ha megpróbálsz a Folyamatos Integráció szerint élni, akkor elkezdesz javítani a tervezési fájdalmakkal, mert másfelé nem tudsz menekülni.
(Oleg) Igen, így van. A munkaigény szempontjából ez a gyakorlat összehasonlítható bármely más komoly gyakorlattal, amely megváltoztatja a kultúrát. A legnehezebb az akadályok leküzdése: különösen a rossz szokások. Ha a gyakorlat bevezetéséhez komoly habitusváltozásokra van szükség a körülötted lévőktől: fejlesztőktől, vezetőségtől, termelési menedzserektől, meglepetések várnak rád.
Milyen meglepetések adódhatnak? Tegyük fel, hogy úgy döntöttél, gyakrabban fogsz integrálni. És az integrációhoz kapcsolódik még néhány dolog, például artefaktumok. A cégedben például van egy politika, hogy minden artefaktumot valami módon nyilván kell tartani egy artefaktumraktározási rendszerben. Ennek pedig van egy időigénye. Az embernek rá kell bólintania, hogy ő, mint kiadással foglalkozó menedzser, tesztelte azt az artefaktumot, hogy alkalmas legyen a production rendszerbe való kihelyezéshez. Ha ez 5-10-15 percet vesz igénybe, de hetente egyszer kihelyezel, akkor hetente fél órát rászánni – ez nem számít nagy terhelésnek.
Ha naponta 10 alkalommal végzel folyamatos integrációt, akkor ezt a 10-et meg kell szorozni 30 perccel. És ez meghaladja ennek a kiadási menedzsernek a munkaidőkeretét. Egyszerűen elfárad ebben. Vannak állandó költségek egyes gyakorlatokra. És ennyi.
Vagy törölnöd kell ezt a szabályt, hogy ne foglalkozz ilyen hülyeségekkel, azaz nem rendelkezel kézzel valamiféle megfelelőségről. Teljes mértékben egy automatizált készségtesztre bízod magad.
Ha szükséged van valakitől egy igazolásra, hogy a főnök aláírja, és nem mersz a production rendszerbe menni anélkül, hogy Vasja azt mondta volna, hogy engedélyezi, stb. – mindenféle zűr megakadályozza a gyakorlatokat. Mert ha vannak kapcsolódó aktivitások, mint valamilyen adó, akkor minden 100-szor nagyobbá válik. Ezért a változás nem mindenkinek örömteli. Mert az emberek szokásait nehéz megváltoztatni.
Amikor az ember megszokott munkát végez, azt gyakorlatilag nem gondolkodva teszi. A kognitív terhelése nulla. Csak elvégzi a feladatokat, már van a fejében egy ellenőrző lista, ezerszer csinálta már. És amint jössz és mondod neki: „Töröljük ezt a gyakorlatot, és hétfőtől vezessünk be egy újat”, ez hatalmas kognitív terhelést okoz számára. Ráadásul ez mindenkire egyszerre hat.
Ezért a legegyszerűbb, igaz, ezt a luxust nem mindenki engedheti meg magának, de én mindig így cselekszem. Amikor elindul egy új projekt, akkor általában az összes kipróbálatlan gyakorlat azonnal ebbe a projektbe kerül. Amíg a projekt fiatal, nem kockáztatunk túl sokat. A prod még nincs kész, így nincs mit romba dönteni. Ezért edzésként is lehet használni. Ez a megközelítés működik. De nem minden cégnek van lehetősége gyakran ilyen projekteket indítani. Bár ez is kicsit furcsa, mert most folyik a digitális transzformáció, mindenkinek kísérleteznie kell, hogy lépést tartson a versenytársakkal.
Itt abba ütközöl, hogy először meg kell értened, mit is kell tenni. A világ nem tökéletes, a prod sem tökéletes.
Igen, ezek a dolgok összefüggnek.
A vállalkozásoknak sem mindig van tudomásuk arról, hogy hova kellene haladniuk.
Van olyan helyzet, amikor semmilyen változás nem lehetséges. Ez a helyzet akkor áll elő, amikor a csapatra nagyobb nyomás nehezedik. A csapat már eléggé kiégett. Nincs idejük kísérletezni. Reggeltől estig új funkciókat fejlesztenek. És a vezetés nem elégedett a funkciókkal, egyre többet követelnek. Ilyen helyzetben valójában semmiféle változás nem lehetséges. Csak annyit tudnak mondani a csapatnak, hogy holnap úgy dolgozunk, mint tegnap, csak egy kicsit több funkciót kell készíteni. Semmilyen gyakorlatra áttérni ebben az értelemben nem lehetséges. Ez egy klasszikus helyzet, amikor nincs idő a balta élezésére, fát kell vágni, ezért tompa baltával vágnak. Itt nincsenek egyszerű tanácsok.
(Dmitrij) Felolvasom a pontosítást a chatról: „De nagy tesztlefedettségre van szükség különböző szinteken. Mennyi időt szánnak a tesztelésre? Valahogy túl drága, sok időt elvesz.”
(Oleg) Ez a klasszikus tévhit. Elég tesztnek kell lennie ahhoz, hogy önbizalommal rendelkezzen. A Continuous Integration nem olyan dolog, ahol először 100%-os teszt következik, és csak utána kezded el alkalmazni ezt a gyakorlatot. A Continuous Integration csökkenti a kognitív terhelést azáltal, hogy minden egyes változtatás, amit a szemed lát, olyan nyilvánvaló, hogy megérted – eltörik-e valamit vagy sem, még tesztelés nélkül is. Fejben gyorsan tesztelheted, mert kicsi a változás. Még ha csak manuális tesztelők is vannak, nekik is könnyebb. Kiadtad, és mondtad: "Nézd, nem törött el semmi?". Ellenőrizték, és azt mondták: "Nem, semmi nem törött el". Mert a tesztelő tudja, hova nézzen. Van egy commit, amely egy kódfoszlányhoz kapcsolódik. És ez konkrét viselkedést produkál.
Itt persze kicsit szépítettél.
(Dmitry) Itt nem értek egyet. Van egy gyakorlat – a tesztelés általi fejlesztés, ami éppen ettől meg fog menteni.
(Oleg) Igen, idáig még nem jutottam el. Az első illúzió az, hogy 100%-os tesztet kell írni, vagy egyáltalán nem kell foglalkozni a Continuous Integration-nel. Ez nem igaz. Ez két párhuzamos gyakorlat. És közvetlenül nem függenek egymástól. A tesztlefedettségednek optimálisnak kell lennie. Az optimális azt jelenti, hogy magabiztos vagy abban, hogy a mestered minősége, amely a commit után maradt, lehetővé teszi, hogy magabiztosan nyomd meg a "Deploy" gombot péntek este, részeg állapotban. Hogyan éred ezt el? Átnézésekkel, lefedettséggel, jó monitorozással.
A jó monitorozás nem különbözik a tesztektől. Ha a teszteket egyszer futtatod a pre prod-on, akkor azok egyszer ellenőrzik az összes felhasználói szcenáriót, és ennyi. De ha végtelen ciklusban futtatod őket, akkor ez a kibővített monitorozási rendszered, ami végtelenül mindent tesztel – összeomlott-e vagy sem. Ebben az esetben a különbség csak az egyszeri vagy többszöri futtatás. Egy nagyon jó tesztkészlet…, amelyet végtelenül futtatsz, ez a monitorozás. És a helyes monitorozásnak pontosan ilyennek kell lennie.
És ezért, hogyan éred el ezt az állapotot, amikor péntek este ki tudsz telepíteni, és hazamehetsz, az egy másik kérdés. Lehet, hogy egyszerűen merész vagy.
Nézzünk vissza kicsit a Continuous Integration-re. Kissé eltértünk egy olyan összetett gyakorlatra.
A második illúzió pedig az, hogy az MVP-t gyorsan kell elkészíteni, ezért ott a tesztek egyáltalán nem szükségesek. Ez nem egészen így van. Az a helyzet, hogy amikor MVP-t írsz, a user story-t vagy úgy fejleszted, hogy hallottad, van egy user story és azonnal nekiállsz kódolni, vagy TDD alapján dolgozol. És a TDD szerint, ahogy a gyakorlat mutatja, nem is tart tovább, azaz a tesztek melléktermékek. A TDD gyakorlata nem arról szól, hogy teszteljünk. Annak ellenére, hogy Test Driven Development-nek hívják, itt valójában nem a tesztekről van szó. Ez inkább egy architekturális megközelítés. Ez az a megközelítés, hogyan írjuk azt, amire szükség van, és ne írjunk olyat, amire nincs szükség. Ez a gyakorlat a figyelem összpontosítására vonatkozik a gondolatod következő iterációjára az alkalmazás architektúrájának létrehozása során.
Ezért ezeket az illúziókat nem olyan egyszerű megszüntetni. Az MVP és a tesztek nem zárják ki egymást. Inkább ellenkezőleg, ha az MVP-t TDD gyakorlat szerint készíted, akkor jobban és gyorsabban készül el, mint ha egyáltalán nem alkalmaznád a gyakorlatot, hanem csak úgy, ahogy esik.
Ez egy nagyon nem nyilvánvaló és összetett gondolat. Amikor hallod, hogy most még teszteket is írok, és így gyorsabban elvégzek valamit, ez teljesen ésszerűtlenül hangzik.
(Dmitrij) Itt sokan, amikor MVP-t emlegetnek, a nép lustasága miatt nem akarnak normálisan írni. És ezek mégis különböző dolgok. Az MVP-t ne változtassuk valami rossz dologgá, ami nem működik.
Igen, igazad van.
Aztán hirtelen az MVP a produkciós környezetbe.
Örökre.
A TDD nagyon szokatlanul hangzik, amikor hallod, hogy tesztet írsz, és látszólag több munkát végzel. Ez nagyon furcsán hangzik, de valójában így gyorsabb és szebb is. Amikor írsz egy tesztet, már a fejedben sokat gondolsz arra, milyen kódot írsz, és hogyan fogják azt hívni, valamint milyen viselkedést várunk tőle. Nem csak azt mondod, hogy írtam egy funkciót, és az valamit csinál. Először átgondolod, hogy ezek a feltételek vannak, így fognak hívni. Ezt te tesztekkel feded le, és ebből megérted, hogyan fognak kinézni a kódod belső interfészei. Ez nagyon erősen hat az architektúrára. A kódod automatikusan modulárisabbá válik, mert először próbálod megérteni, hogyan fogod azt tesztelni, és csak utána írod meg.
Nálam a TDD úgy alakult, hogy egy időben egy Ruby mentort fogadtam, mikor még Ruby programozó voltam. Azt mondja: „Csinálj TDD-t”. Én meg gondoltam: „Jaj, most még valamit pluszban kellene írnom”. Megállapodtunk, hogy két hét alatt minden munka kódot Pythonban TDD alatt írok. Két hét múlva rájöttem, hogy nem akarok visszatérni. Két hét próbálkozás után, hogy ezt mindenhol alkalmazzam, észrevettem, hogy mennyivel könnyebb már csak gondolkodni. De ez nem nyilvánvaló, ezért mindenkinek azt javaslom, hogy ha úgy érzi, a TDD nehéz, hosszadalmas és felesleges, próbálja meg két hétig követni. Nekem ez elegendő volt.
(Dmitrij) Ezt a gondolatot az infrastruktúra üzemeltetésének szempontjából is kifejthetjük. Mielőtt valami újat indítunk, monitorozunk, majd indítunk. Ebben az esetben a monitorozás normális tesztelés mellett zajlik. És a monitorozás által történik a fejlesztés. De szinte mindenki azt mondja, hogy ez hosszadalmas, lusta vagyok, csináltam egy ideiglenes vázlatot. Ha normálisan monitoroztunk, megértjük a CI rendszer állapotát. A CI rendszerben sok a monitorozás. Megértjük a rendszer állapotát, tudjuk, mi folyik benne. A fejlesztés során éppen azt csináljuk, hogy a rendszer eljusson a szükséges állapotba.
Ezek a gyakorlatok régóta ismertek. Körülbelül négy éve beszéltünk erről. De négy év alatt szinte semmi sem változott.
De ezen a megjegyzésen javaslom, hogy zárjuk le a hivatalos vitát.
Videó (beágyazva mint médiaelem, de valamiért nem működik):
Forrás: habr.com
