A DevOps gyakorlatok működnek. Erről mi magunk is meggyőződtünk, amikor 10-szeresére csökkentettük a kiadás telepítési idejét. A VTB-nél használt FIS Profile rendszerben a telepítés most 90 helyett 10 percet vesz igénybe. A kiadás felépítési ideje két hétről két napra csökkent. A tartós megvalósítási hibák száma szinte a minimumra csökkent. Ahhoz, hogy megszabaduljunk a „kézi munkától”, és kiküszöböljük az eladótól való függést, mankóval kellett dolgoznunk, és váratlan megoldásokat kellett találnunk. A vágás alatt egy részletes történet arról, hogyan építettünk fel egy teljes értékű belső fejlesztést.
Prológus: A DevOps egy filozófia
Az elmúlt évben sokat dolgoztunk a DevOps gyakorlatok belső fejlesztésének és bevezetésének megszervezésén a VTB-nél:
- 12 rendszerhez építettünk ki belső fejlesztési folyamatokat;
- 15 csővezetéket indítottunk el, ebből négyet termelésbe bocsátottunk;
- Automatizált 1445 tesztforgatókönyv;
- Sikeresen megvalósítottunk számos belső csapat által készített kiadást.
A DevSecOps gyakorlatok egyik legnehezebben megszervezhető házon belüli fejlesztése és megvalósítása a FIS Profile rendszer volt – egy kiskereskedelmi termékfeldolgozó egy nem relációs DBMS-en. Ennek ellenére meg tudtuk építeni a fejlesztést, elindítottuk a folyamatot, egyedi, nem kiadású csomagokat telepíthettünk a termékre, és megtanultuk a kiadások összeállítását. A feladat nem volt könnyű, de érdekes és nyilvánvaló megkötések nélkül a megvalósításban: itt a rendszer - házon belüli fejlesztést kell felépíteni. Az egyetlen feltétel az, hogy a CD-t produktív környezet előtt használjuk.
Eleinte a megvalósítási algoritmus egyszerűnek és világosnak tűnt:
- Kialakítjuk a kezdeti fejlesztési szakértelmet, és elfogadható minőségi szintet érünk el a kódcsapattól durva hibák nélkül;
- A lehető legnagyobb mértékben integráljuk a meglévő folyamatokba;
- A nyilvánvaló szakaszok közötti kód átviteléhez egy csővezetéket vágunk, és az egyik végét a folytatásba toljuk.
Ez idő alatt a szükséges méretű fejlesztőcsapatnak készségeket kell fejlesztenie, és elfogadható szintre kell növelnie a kiadásokhoz való hozzájárulását. És ennyi, a feladatot befejezettnek tekinthetjük.
Úgy tűnik, ez egy teljesen energiatakarékos út a kívánt eredményhez: itt a DevOps, itt a csapat teljesítménymutatói, itt a felhalmozott szakértelem... De a gyakorlatban újabb megerősítést kaptunk, hogy a DevOps még mindig a filozófiáról szól. , és nem „a gitlab folyamathoz kötve, az ansible, a nexus és a lista lejjebb található”.
Az akciótervet még egyszer elemezve rájöttünk, hogy egyfajta outsource szállítót építünk magunkban. Ezért a fent ismertetett algoritmus mellé a folyamat-újratervezést, valamint a teljes fejlesztési útvonalon a szakértelem fejlesztését egészítettük ki, hogy ebben a folyamatban vezető szerepet kapjunk. Nem a legegyszerűbb lehetőség, de ez az ideológiailag helyes fejlődés útja.
Hol kezdődik a házon belüli fejlesztés?
Nem ez volt a legbarátságosabb rendszer a munkához. Építészetileg egy nagy, nem relációs DBMS volt, sok külön végrehajtható objektumból (szkriptek, eljárások, kötegek stb.) állt, amelyeket szükség szerint hívtak meg, és a fekete doboz elvén működött: fogadja a kéréseket és problémákat. egy válasz. Egyéb nehézségek, amelyeket érdemes megemlíteni:
- Egzotikus nyelv (MUMPS);
- konzol interfész;
- A népszerű automatizálási eszközökkel és keretrendszerekkel való integráció hiánya;
- Adatmennyiség tíz terabájtban;
- Több mint 2 millió művelet óránként;
- Jelentősége – üzleti szempontból kritikus.
Ugyanakkor a mi oldalunkon nem volt forráskód-tárház. Egyáltalán. Volt dokumentáció, de minden kulcsfontosságú tudás és kompetencia egy külső szervezet oldalán volt.
A rendszer fejlesztésének elsajátítását szinte a nulláról kezdtük, figyelembe véve annak jellemzőit és alacsony elosztását. 2018 októberében indult:
- Tanulmányozta a dokumentációt és a kódgenerálás alapjait;
- Tanulmányoztuk az eladótól kapott rövid fejlesztési tanfolyamot;
- Elsajátította a kezdeti fejlesztési készségeket;
- Összeállítottunk egy képzési kézikönyvet az új csapattagok számára;
- Megállapodtunk, hogy a csapatot „harc” módba kapcsoljuk;
- Megoldotta a problémát a kódminőség-ellenőrzéssel;
- A fejlesztésért standot szerveztünk.
Három hónapot töltöttünk a szakértelem fejlesztésével és a rendszerben való elmélyüléssel, és 2019 elejétől a házon belüli fejlesztés néha nehezen, de magabiztosan és céltudatosan megindult a szép jövő felé.
Repository migráció és automatikus tesztek
Az első DevOps-feladat a tároló. Gyorsan megegyeztünk a hozzáférés biztosításában, de át kellett térni a jelenlegi egy törzságú SVN-ről a cél Gitre a több ágból álló modellre való átállással és a Git Flow fejlesztésével. Van még 2 csapatunk saját infrastruktúrával, plusz a szállító külföldi csapatának egy része. Két Gittel kellett élnem, és biztosítanom kellett a szinkronizálást. Ilyen helyzetben ez a két rossz közül a kisebbik volt.
A tár migrációját többször is elhalasztották, csak áprilisban fejezték be, a frontvonalbeli kollégák segítségével. A Git Flow-val úgy döntöttünk, hogy kezdetnek egyszerűnek tartjuk a dolgokat, és a klasszikus sémára helyeztük a gyorsjavítást, fejlesztést és kiadást. Úgy döntöttek, hogy elhagyják a mestert (más néven prod-like). Az alábbiakban elmagyarázzuk, miért bizonyult számunkra ez a lehetőség optimálisnak. A szállítóhoz tartozó, két csapat számára közös külső adattárat használtak munkásként. Ütemezés szerint szinkronizálódott a belső tárhellyel. Most a Git és a Gitlab segítségével lehetővé vált a folyamatok automatizálása.
Az autotesztek kérdése meglepően könnyen megoldódott - kész keretrendszert kaptunk. A rendszer sajátosságait figyelembe véve a külön művelet elhívása érthető része volt az üzleti folyamatnak, és egyben egységtesztként is szolgált. Már csak a tesztadatok előkészítése és a szkriptek meghívásának és az eredmények kiértékelésének kívánt sorrendjének beállítása volt hátra. A működési statisztika, a folyamatok kritikussága és a meglévő regressziós módszertan alapján kialakított forgatókönyvek listája kitöltésével elkezdtek megjelenni az automatikus tesztek. Most elkezdhetjük a csővezeték építését.
Hogyan volt: az automatizálás előtti modell
A megvalósítási folyamat jelenlegi modellje egy külön történet. Minden módosítást manuálisan vittek át külön növekményes telepítőcsomagként. Következett a kézi regisztráció a Jira-ban és a manuális telepítés a környezetekre. Az egyes csomagok esetében minden egyértelműnek tűnt, de a kiadás előkészítésével a dolgok bonyolultabbak voltak.
Az összeszerelés egyedi szállítások szintjén történt, amelyek önálló objektumok voltak. Minden változtatás új szállítást jelent. Többek között 60-70 technikai változatot adtunk a fő kiadási összetétel 10-15 csomagjához - olyan verziók, amelyeket akkor kaptak, amikor hozzáadtunk vagy kizártunk valamit a kiadásból, és amelyek tükrözik a kiadásokon kívüli eladások változásait.
A szállításokon belüli objektumok átfedték egymást, különösen a végrehajtható kódban, amely kevesebb, mint fele volt egyedi. Sok függőség volt mind a már telepített kódtól, mind attól, amelynek telepítését csak tervezték.
A kód szükséges verziójának megszerzéséhez szigorúan be kellett tartani a telepítési sorrendet, amely során sokszor, néhányszor 10-12 alkalommal is átírták az objektumokat.
Egy csomó csomag telepítése után manuálisan kellett követnem az utasításokat a beállítások inicializálásához. A kiadást az eladó szerelte össze és telepítette. A kiadás összetételét már szinte a megvalósítás pillanata előtt tisztázták, ami a „leválasztási” csomagok létrehozásával járt. Ennek eredményeként a készletek jelentős része kibocsátásról kiadásra költözött saját „lecsatolási” farkával.
Most már világos, hogy ezzel a megközelítéssel – csomagszinten összerakva a kiadási rejtvényt – egyetlen mesterágnak nem volt gyakorlati értelme. Az üzembe helyezés másfél-két óra kézi munkát vett igénybe. Még jó, hogy legalább telepítői szinten megadták az objektumfeldolgozás sorrendjét: mezők és struktúrák kerültek a rájuk és az eljárásokra vonatkozó adatok elé. Ez azonban csak egy külön csomagban működött.
Ennek a megközelítésnek a logikus eredménye a kötelező telepítési hibák az objektumok elferdített változatai, a szükségtelen kódok, a hiányzó utasítások és az objektumok fel nem számolt kölcsönös befolyásolása formájában, amelyeket a kiadás után lázasan megszüntettek.
Első frissítések: az összeszerelést és a szállítást
Az automatizálás a kód továbbításával kezdődött egy csövön keresztül a következő útvonalon:
- Vegye fel a kész szállítmányt a raktárból;
- Telepítse egy dedikált környezetre;
- Futtasson automatikus teszteket;
- Értékelje a telepítés eredményét;
- Hívja meg a következő folyamatot a tesztelési parancs oldalán.
A következő folyamatnak regisztrálnia kell a feladatot a Jira-ban, és meg kell várnia, amíg a parancsok elosztásra kerülnek a kiválasztott tesztelési ciklusokhoz, amelyek a feladat végrehajtásának időzítésétől függenek. Trigger - egy levél, amely arról szól, hogy készen áll a kézbesítésre egy adott címre. Ez persze nyilvánvaló mankó volt, de valahol el kellett kezdenem. 2019 májusában a kódátvitel a környezetünk ellenőrzésével kezdődött. A folyamat elkezdődött, már csak a tisztességes formába hozása van hátra:
- Minden módosítás egy külön ágban történik, amely megfelel a telepítőcsomagnak, és beolvad a cél fő ágba;
- A folyamatindítási eseményindító egy új véglegesítés megjelenése a fő ágban egy összevonási kérelem révén, amelyet a belső csapat karbantartói zárnak le;
- A tárolók ötpercenként szinkronizálódnak;
- A telepítőcsomag összeállítása elindul - a szállítótól kapott assembler segítségével.
Ezek után már megvoltak a lépések a kód ellenőrzésére és átvitelére, a cső elindítására és az oldalunkon történő összeszerelésre.
Ez az opció júliusban jelent meg. Az átállás nehézségei némi elégedetlenséget eredményeztek a gyártó és az élvonal körében, de a következő hónap során sikerült minden durva élt eltüntetni, és egy folyamatot kialakítani a csapatok között. Mostantól van szerelés és szállítás.
Augusztusban sikerült egy különálló csomag első üzembe helyezése a gyártási folyamaton a csővezetékünk segítségével, szeptember óta pedig kivétel nélkül az egyedi, nem kiadású csomagok telepítése a CD-eszközünkön keresztül történt. Ráadásul a gyártónál kisebb csapattal sikerült elérni a házon belüli feladatok 40%-át a kiadási összetételben – ez határozott siker. A legkomolyabb feladat maradt - a kiadás összeállítása és telepítése.
A végső megoldás: kumulatív telepítőcsomagok
Tökéletesen megértettük, hogy a szállítói utasítások szkriptezése olyan automatizálás volt, át kellett gondolnunk magát a folyamatot. A megoldás kézenfekvő volt - összegyűjteni a kiadási ágból a szükséges verziók összes objektumát.
A koncepció bizonyításával kezdtük: a korábbi implementáció tartalmának megfelelően kézzel összeállítottuk a kiadási csomagot, és telepítettük a környezetünkre. Minden sikerült, a koncepció életképesnek bizonyult. Ezután megoldottuk az inicializálási beállítások szkriptelésének és a véglegesítésbe való felvételének problémáját. A kontúrfrissítés részeként egy új csomagot készítettünk és teszteltünk tesztkörnyezetben. A telepítés sikeres volt, bár sokféle észrevételt fűzött a végrehajtó csapattól. De a lényeg az, hogy a novemberi kiadásban az összeállításunkkal kaptunk engedélyt a gyártás megkezdésére.
Alig több mint egy hónap volt hátra, a kézzel válogatott kellékek egyértelműen utaltak arra, hogy az idő fogy. Úgy döntöttek, hogy a kiadási ágból készítik el a buildet, de miért kellene szétválasztani? Nincs Prod-szerű programunk, és a meglévő ágak sem jók – sok a felesleges kód. Sürgősen le kell vágnunk a prod-liket, és ez több mint háromezer commit. A kézi összeszerelés egyáltalán nem lehetséges. Felvázoltunk egy szkriptet, amely végigfut a termék telepítési naplóján, és összegyűjti az ágra vonatkozó kötelezettségvállalásokat. Harmadszorra már rendesen működött, és „reszelős befejezés” után készen is volt az ág.
Saját készítőt írtunk a telepítési csomaghoz, és egy hét alatt elkészültünk vele. Ezután a telepítőt kellett módosítanunk a rendszer alapfunkcióiból, mivel az nyílt forráskódú. A sorozatos ellenőrzések és módosítások után az eredmény sikeresnek minősült. Időközben formát öltött a kiadás összetétele, melynek helyes telepítéséhez a tesztkört a gyártási áramkörhöz kellett igazítani, ehhez külön forgatókönyvet írtak.
Természetesen sok megjegyzés érkezett az első telepítéshez, de összességében a kód működött. És körülbelül a harmadik telepítés után minden kezdett jól kinézni. Az objektumok kompozíció- és verzióvezérlését külön-külön figyelték kézi üzemmódban, ami ebben a szakaszban meglehetősen indokolt volt.
További kihívást jelentett a nem-kiadások nagy száma, amellyel számolni kellett. De a Prod-szerű ág és a Rebase segítségével a feladat átláthatóvá vált.
Első alkalommal, gyorsan és hiba nélkül
Optimista hozzáállással és több mint egy tucat sikeres telepítéssel közelítettük meg a kiadást különböző áramkörökön. De szó szerint egy nappal a határidő lejárta előtt kiderült, hogy az eladó nem fejezte be az elfogadott módon a telepítés előkészítését. Ha valamilyen okból a buildünk nem működik, a kiadás megszakad. Sőt, erőfeszítéseink révén, ami különösen kellemetlen. Nem volt módunk a visszavonulásra. Ezért átgondoltuk az alternatív lehetőségeket, elkészítettük a cselekvési terveket és megkezdtük a telepítést.
Meglepő módon a teljes, több mint 800 objektumból álló kiadás az első alkalommal helyesen indult, mindössze 10 perc alatt. Egy órát töltöttünk a naplók ellenőrzésével, hibákat keresve, de nem találtunk.
Egész másnap csend volt a kiadási csevegésben: nem volt implementációs probléma, ferde verziók vagy „nem megfelelő” kód. Még ez valahogy kínos is volt. Később megjelent néhány megjegyzés, de más rendszerekhez és a korábbi tapasztalatokhoz képest ezek száma és prioritása érezhetően alacsonyabb volt.
A kumulatív hatás további hatása az összeszerelés és a tesztelés minőségének javulása volt. A teljes kiadás többszöri telepítése miatt a felépítési hibákat és a telepítési hibákat időben azonosították. A teljes kiadású konfigurációkban végzett tesztelés lehetővé tette az objektumok kölcsönös befolyásának hibáinak további azonosítását, amelyek nem jelentek meg a növekményes telepítés során. Határozottan sikeres volt, különösen, ha 57%-os hozzájárulást adtunk a kiadáshoz.
Eredmények és következtetések
Kevesebb, mint egy év alatt sikerült:
- Egy egzotikus rendszer segítségével teljes értékű belső fejlesztést építsen fel;
- A kritikus szállítói függőség megszüntetése;
- Indítsa el a CI/CD-t egy nagyon barátságtalan örökségért;
- A megvalósítási folyamatok új technikai szintre emelése;
- Jelentősen csökkenti a telepítési időt;
- Jelentősen csökkenti a megvalósítási hibák számát;
- Nyugodtan vallja magát vezető fejlesztési szakértőnek.
Természetesen a leírtak nagy része egyenesen baromságnak tűnik, de ezek a rendszer jellemzői és a benne létező folyamatkorlátok. A változások jelenleg az IS Profile termékeket és szolgáltatásokat (főszámlák, plasztikkártyák, megtakarítási számlák, letéti számlák, készpénzhitelek) érintették, de potenciálisan minden olyan IS-re alkalmazható a megközelítés, amelyre a DevOps gyakorlatok megvalósításának feladata van. A kumulatív modell biztonságosan replikálható számos szállításból származó későbbi implementációkhoz (beleértve a nem kiadásúakat is).
Forrás: will.com