A valódi különbség a folyamatos integráció és a folyamatos telepítés között

Rengeteg olyan tartalom van, amely leírja, hogy mi a folyamatos integráció, a folyamatos kézbesítés és a folyamatos telepítés. De milyen célokat szolgálnak elsősorban ezek a folyamatok?

Elengedhetetlen a CI és a CD által megoldott problémák megértése a megfelelő használat érdekében. Ez lehetővé teszi a csapatának, hogy javítsa a folyamatot, és elkerülje az erőfeszítéseket olyan divatos mutatók üldözésében, amelyek nem jelentenek értéket a folyamatnak.

A folyamatos integráció csapatprobléma

Ha csapatban dolgozik, akkor nagy valószínűséggel több fejlesztő dolgozik ugyanazon a táron. A tárban van egy fő ág, amely a kód legújabb verzióját tartalmazza. A fejlesztők különböző dolgokon dolgoznak, különböző ágakon. Miután valaki végzett a változásával, kitolja vagy beolvasztja a fő ágba. Végül az egész csapat kihúzza ezt a változást.

Az a forgatókönyv, amelyet el akarunk kerülni, az, hogy egy hibás elkötelezettség a fő ágra kerül. Hibás azt jelenti, hogy a kód nem fordul össze, vagy az alkalmazás nem indul el, vagy használhatatlan. Miért? Nem azért, mert az alkalmazás nem működik, vagy azért, mert az összes tesztnek mindig zöldnek kell lennie. Ez nem probléma - dönthet úgy, hogy nem telepíti ezt a verziót, és várhat a javításra.

A probléma az, hogy az egész csapat elakadt. Az összes fejlesztő, aki kihúzta a hibás elkötelezettséget, 5 percig azon gondolkodik, miért nem működik. Többen valószínűleg megpróbálják megtalálni a hibás elkötelezettséget. Néhányan a hibás kódszerzővel párhuzamosan megpróbálják egyedül megoldani a problémát.

Ez időpazarlás a csapat számára. A legrosszabb, hogy az ismétlődő események bizalmatlanságot okoznak a fő ággal szemben, és a fejlesztőket különálló munkára ösztönzik.

A folyamatos integráció célja, hogy megakadályozza a fő ág törését, hogy csapata ne ragadjon. Ez az. Ez nem arról szól, hogy minden teszt zöld minden alkalommal, és a fő ága bevethető a termelés minden elkövetni.

A folyamatos integráció folyamata független minden eszköztől. Manuálisan ellenőrizheti, hogy az ág és a fő ág egyesítése lokálisan működik-e, majd az egyesítést ténylegesen csak a lerakatba tolhatja. De ez nagyon nem hatékony. Ezért a folyamatos integrációt automatizált ellenőrzésekkel valósítják meg.

Az ellenőrzések biztosítják, hogy a minimumon:

  • Az alkalmazásnak fel kell építenie és el kell indulnia
  • A legtöbb kritikus funkciónak mindig működőképesnek kell lennie (felhasználói feliratkozás / bejelentkezés útja és üzleti főbb jellemzők)
  • Az alkalmazás közös rétegeinek, amelyekre az összes fejlesztő támaszkodik, stabilnak kell lenniük. Ez azt jelenti, hogy az alkatrészeket egységesen tesztelik.

A gyakorlatban ez azt jelenti, hogy meg kell húznia az Ön számára megfelelő egységteszt keretrendszert, és meg kell védenie az alkalmazás közös rétegeit. Néha nem olyan sok a kód, és elég gyorsan meg lehet csinálni. Ezenkívül hozzá kell adnia egy „füsttesztet” is, amely igazolja, hogy a kód összeáll és az alkalmazás elindul. Ez különösen fontos az olyan őrült függőségi injekciókkal rendelkező technológiákban, mint a Java Spring vagy a .NET core. Nagy projekteknél olyan könnyű félrevezetni a függőségeket, hogy annak ellenőrzése, hogy az alkalmazás mindig elindul-e, elengedhetetlen.

Ha több száz vagy ezer teszted van, nem kell mindegyiket futtatnod minden egyesítéshez. Sok időbe fog telni, és a legtöbb teszt valószínűleg igazolja a "nem csapatblokkoló" funkciókat.

A következő szakaszokban meglátjuk, hogy a folyamatos kézbesítés folyamata hogyan fogja jól kihasználni ezt a sok tesztet.

Nem az eszközökről szól

Az eszközök és az automatizált ellenőrzések rendben vannak. De ha a fejlesztői csak egyesítik azokat az óriási ágakat, amelyeken hetekig dolgoznak, akkor nem segítenek. A csapat sok időt fog tölteni az ágak összevonásával és a végül felmerülő kód-összeférhetetlenségek kijavításával. Ugyanolyan időpazarlás, mint ha hibás elkötelezettség akadályozza.

A folyamatos integráció nem az eszközökről szól. Arról szól, hogy apró darabokban dolgozzon, és új kódját integrálja a fő ágba, és gyakran húzza.

Gyakran azt jelenti, hogy legalább naponta. Bontsa fel a feladatot, amelyen dolgozik, kisebb feladatokra. Nagyon gyakran egyesítse a kódot, és nagyon gyakran húzza meg. Így senki nem dolgozik külön-külön egy-két napnál tovább, és a problémákra nincs idő hógolyóvá válni.

A nagy feladatnak nem kell minden egy ágban lennie. Soha nem szabad. A folyamatban lévő munka és a fő ág egyesítésének technikáit "absztrakció útján történő elágazásnak" és "funkcióváltásoknak" nevezzük. További részletekért olvassa el a Hogyan kezdjük el a folyamatos integrációt című blogbejegyzést.

A jó CI-felépítés kulcsfontosságú pontjai

Nagyon egyszerű. Legyen rövid. 3-7 perc legyen a max. Nem a CPU-ról és az erőforrásokról szól. A fejlesztők termelékenységéről szól. A termelékenység első szabálya a fókusz. Tegyen egy dolgot, fejezze be, majd lépjen a következő dologra.

A kontextusváltás költséges. A tanulmányok azt mutatják, hogy ~ 23 percbe telik, mire mélyen át kell fókuszálni valamire, ha megzavarodsz.

Képzeld el, hogy az ágadat egyesíted. Elkezd egy másik feladatot. 15-20 percet töltesz bele. A zónában tartózkodása után egy perccel kap egy "sikertelen összeállítás" értesítést az előző feladat 20 perces CI-összeállításától. Visszajössz, hogy kijavítsd. Újra nyomja. Könnyedén vesztett több mint 20 percet oda-vissza mozogva.

Szorozzon naponta egyszer vagy kétszer 20 percet a csapat fejlesztőinek számával ... Ez sok értékes időt veszít el.

Most képzelje el, hogy a visszajelzés 3 percen belül érkezett-e. Valószínűleg egyáltalán nem kezdte volna el az új feladatot. Bizonyíték lenne arra, hogy még egyszer elolvassa a kódot, vagy várakozás közben átnézte a PR-t. A sikertelen értesítés jön, és Ön kijavítja. Ezután folytathatja a következő feladattal. Ez az a fókusz, amelyet a folyamatnak lehetővé kell tennie.

Ha rövid ideig tart a CI felépítése, az kompromisszumot jelent. A hosszabb ideig futó vagy a CI kontextusában kevés értéket biztosító teszteket át kell helyezni a CD lépésbe. És igen, az ottani kudarcokat is orvosolni kell. De mivel senkit sem akadályoznak a dolguk elvégzésében, a javításokat "következő feladatként" vehetjük, amikor befejezzük, amit csinálunk. Csak kapcsolja ki az értesítéseket munka közben, és ellenőrizze hébe-hóba. Tartsa a minimálisra váltott kontextust.

A folyamatos szállítás és a telepítés mérnöki probléma

Térjünk rá a definíciókra, hogy ezt elkerüljük.

A folyamatos kézbesítés arról szól, hogy a kód bármely verzióját bármikor telepítheti. A gyakorlatban ez a kódod utolsó vagy előtti verzióját jelenti. Nem telepíti automatikusan, általában azért, mert nem kell, vagy korlátozza a projekt életciklusa. De amint valaki kedvet érez, a telepítés minimális idő alatt elvégezhető. Hogy valaki lehet az a teszt / minőségbiztosítási csapat, amely ki akarja próbálni a dolgokat egy színpadi vagy gyártás előtti környezetben. Vagy valójában itt lehet az ideje, hogy a kódot kibocsássa a termelésbe.

A folyamatos szállítás ötlete az, hogy a tárgyakat a lehető legközelebb készítse elő attól, amit a környezetében futtatni szeretne. Ezek lehetnek .jar vagy .war fájlok, ha Java-val dolgoznak, vagy futtatható fájlok, ha .NET-kel dolgoznak. Ezek lehetnek átmásolt JS-kód mappái vagy akár Docker-tárolók is, bármi is teszi a telepítést rövidebbé (azaz előre elkészítettük, amennyire csak lehet).

A műtermékek előkészítésén nem azt értem, hogy a kódot műtermékekké változtassuk. Ez általában néhány parancsfájl és perc végrehajtás. Előkészítés:

Futtasson minden tesztet annak biztosítása érdekében, hogy a telepítés után a kód valóban működik. Futtasson egységteszteket, integrációs teszteket, végpontok közötti teszteket, sőt teljesítményteszteket is, ha ezt automatizálni tudja.

Így kiszűrheti, hogy a fő ág mely verziói készek valóban gyártásra és melyek még nem. Az ideális tesztcsomag:

  • Biztosítja az alkalmazás legfontosabb funkcióinak működését. Ideális esetben minden funkció
  • Gondoskodik arról, hogy ne kerüljön bevezetésre teljesítmény-megszakító, így amikor új verziója eléri a sok felhasználót, esélye van arra, hogy kitartson
  • Szárazon futtathat bármilyen kódfrissítést, amelyre a kódnak szüksége van a meglepetések elkerülése érdekében

Nem kell nagyon gyorsnak lennie. 30 perc vagy 1 óra elfogadható.

A folyamatos telepítés a következő lépés. Bizonyos környezetekbe a kód legfrissebb és gyártásra kész verzióját telepíti. Ideális a gyártás, ha elég megbízik a CD-tesztcsomagban.

Ne feledje, hogy a kontextustól függően ez nem mindig lehetséges vagy megéri a fáradságot. A folyamatos kézbesítés gyakran elegendő a produktivitáshoz, különösen, ha szoros hálózatban dolgozik, és korlátozott környezetek telepíthetők. Az is előfordulhat, hogy a szoftver kiadási ciklusa megakadályozza a nem tervezett telepítéseket.

A folyamatos kézbesítés és a folyamatos telepítés (nevezzük mostantól CD-nek) nem jelentenek csapatproblémát. Arról szólnak, hogy megtalálják a megfelelő egyensúlyt a végrehajtási idő, a karbantartási erőfeszítések és a tesztkészlet relevanciája között, hogy elmondhassák: "Ez a verzió úgy működik, ahogy kellene."

És ez egy egyensúly. Ha a tesztek 30 órán át tartanak, ez problémát jelent. Nézze meg ezt az epikus bejegyzést arról, hogy néz ki az Oracle adatbázis tesztcsomag. De ha annyi időt töltesz a tesztek naprakészen tartásával a legfrissebb kóddal, hogy az akadályozza a csapat fejlődését, az sem jó. Akkor is, ha a tesztcsomagja nagyjából semmit sem biztosít ... alapvetően haszontalan.

Egy ideális világban egy telepíthető artefaktumkészletre van szükségünk a főág számára elkötelezettségenként. Láthatja, hogy vertikális méretezhetőségi problémánk van: minél gyorsabban haladunk a kódról a tárgyakra, annál készebbek vagyunk a kód legújabb verziójának telepítésére.

Mi a nagy különbség?

A folyamatos integráció horizontális méretezhetőségi probléma. Azt szeretné, hogy a fejlesztők gyakran egyesítsék kódjukat, ezért az ellenőrzéseknek gyorsaknak kell lenniük. Ideális esetben percek alatt elkerülhető, hogy a fejlesztők folyamatosan kontextust váltsanak a CI buildjeinek erősen aszinkron visszajelzéseivel.

Minél több fejlesztője van, annál nagyobb számítási teljesítményre van szüksége az összes aktív ág egyszerű ellenőrzéséhez (összeállítás és tesztelés).

Jó CI-felépítés: Nem biztosít olyan kódot, amely megszakítja az alapvető dolgokat, és megakadályozza a csapat többi tagjának munkáját, és elég gyors ahhoz, hogy percek alatt visszajelzést adjon a fejlesztőknek, hogy megakadályozza a kontextus váltását a feladatok között.

A folyamatos szállítás és a telepítés vertikális méretezhetőségi probléma. Egy meglehetősen összetett műveletet kell végrehajtania.

Jó CD-felépítés: Biztosítja, hogy a lehető legtöbb funkció megfelelően működjön. Minél gyorsabban, annál jobb, de ez nem a sebesség kérdése. A 30-60 perces összeállítás rendben van.

Gyakori tévhit, hogy a CD-t horizontális skálázhatósági problémának tekintik, mint a CI: minél gyorsabban mozoghat kódról műtermékre, annál több elkötelezettséget tud feldolgozni, és annál közelebb áll az ideális forgatókönyvhöz.

De erre nincs szükségünk. Artefaktumok készítése minden elkötelezettséghez és a lehető leggyorsabban általában túlzott. Nagyon jól megközelítheti a CD-t a legjobb erőfeszítések alapján: legyen egyetlen CD-jének összeállítása, amely csak kiválasztja a legfrissebb elkötelezettséget az ellenőrzéshez, miután az adott build elkészült.

Ne tévedjen a CD-vel. Nagyon nehéz. Megfelelő tesztbiztonság elérése, hogy azt mondhassa, a szoftver automatikusan készen áll a telepítésre, általában alacsony felületű alkalmazásokon, például API-kon vagy egyszerű felhasználói felületeken működik. Nagyon nehéz elérni komplex felhasználói felületen vagy nagy monolit rendszeren.

Következtetés

A CI és a CD végrehajtásához használt eszközök és elvek gyakran nagyon hasonlóak. A célok azonban nagyon különbözőek.

A folyamatos integráció kompromisszumot jelent a fejlesztőknek küldött visszacsatolási sebesség és az elvégzett ellenőrzések (összeállítás és tesztelés) relevanciája között. Semmi olyan kód, amely akadályozná a csapat fejlődését, ne kerüljön a fő ágba.

A telepítés folyamatos kézbesítése arról szól, hogy minél alaposabban ellenőrizze a kódot. Az ellenőrzések teljessége a legfontosabb tényező. Általában a kód lefedettségével vagy a tesztek funkcionális lefedettségével mérik. A hibák korai elkapása megakadályozza, hogy a meghibásodott kód bármilyen környezetbe kerüljön, és megtakarítja a tesztcsoport értékes idejét.

Készítse el CI- és CD-felépítéseit e célok elérése és a csapat produktivitásának fenntartása érdekében. Egyetlen munkafolyamat sem tökéletes. A problémák hébe-hóba merülnek fel. Használja őket tanulságként, hogy minden alkalommal megerősítse munkafolyamatát.

Publikálva 2019. november 27-én a Fire CI blogon.