Prakse DevOps delujejo. O tem smo se prepričali tudi sami, ko smo čas namestitve izdaje skrajšali za 10-krat. V sistemu FIS Profile, ki ga uporabljamo pri VTB, namestitev zdaj traja 90 minut namesto 10. Čas gradnje izdaje se je zmanjšal z dveh tednov na dva dni. Število trajnih napak pri implementaciji se je zmanjšalo skoraj na minimum. Da bi se izognili »fizičnemu delu« in odpravili odvisnost od prodajalca, smo morali delati z berglami in iskati nepričakovane rešitve. Pod rezom je podrobna zgodba o tem, kako smo zgradili polnopravni notranji razvoj.
Prolog: DevOps je filozofija
V zadnjem letu smo opravili veliko dela za organizacijo notranjega razvoja in implementacije praks DevOps v VTB:
- Zgradili smo notranje razvojne procese za 12 sistemov;
- Zagnali smo 15 cevovodov, od tega štiri v proizvodnjo;
- 1445 avtomatiziranih testnih scenarijev;
- Uspešno smo implementirali številne objave, ki so jih pripravile interne ekipe.
Izkazalo se je, da je bil sistem FIS Profile sistem FIS Profile – maloprodajni produktni procesor na nerelacijskem DBMS-ju eden najtežjih za organiziranje internega razvoja in izvajanja praks DevSecOps. Kljub temu smo lahko zgradili razvoj, zagnali cevovod, na izdelek namestili posamezne pakete brez izdaje in se naučili sestavljati izdaje. Naloga ni bila lahka, a zanimiva in brez očitnih omejitev pri izvajanju: tukaj je sistem - zgraditi morate interni razvoj. Edini pogoj je uporaba CD-ja pred produktivnim okoljem.
Sprva se je algoritem izvajanja zdel preprost in jasen:
- Razvijamo začetno razvojno strokovno znanje in dosegamo sprejemljivo raven kakovosti iz kodne ekipe brez večjih napak;
- V čim večji meri se vključujemo v obstoječe procese;
- Za prenos kode med očitnimi stopnjami prerežemo cevovod in enega od njegovih koncev potisnemo v nadaljevanje.
V tem času mora razvojna ekipa zahtevane velikosti razviti veščine in povečati delež svojega prispevka k izdajam na sprejemljivo raven. In to je to, lahko štejemo, da je naloga opravljena.
Zdi se, da je to povsem energijsko učinkovita pot do zahtevanega rezultata: tukaj je DevOps, tu so metrike uspešnosti ekipe, tu je zbrano strokovno znanje ... A v praksi smo dobili še eno potrditev, da je DevOps še vedno filozofija. , in ne "priložen procesu gitlab, ansible, nexus in nižje na seznamu."
Ob ponovni analizi akcijskega načrta smo ugotovili, da v sebi gradimo nekakšnega zunanjega izvajalca. Zato smo zgoraj opisanemu algoritmu dodali prenovo procesov in razvoj strokovnega znanja na celotni razvojni poti za dosego vodilne vloge v tem procesu. Ni najlažja možnost, vendar je to pot ideološko pravilnega razvoja.
Kje se začne interni razvoj?
To ni bil najbolj prijazen sistem za delo. Arhitekturno je šlo za en velik nerelacijski DBMS, sestavljen iz številnih ločenih izvedljivih objektov (skripte, procedure, paketi itd.), ki so jih klicali po potrebi in je deloval po principu črne skrinjice: prejme zahtevo in izda odgovor. Druge težave, ki jih je vredno omeniti, vključujejo:
- Eksotični jezik (MUMPS);
- Konzolni vmesnik;
- Pomanjkanje integracije s priljubljenimi orodji in ogrodji za avtomatizacijo;
- Količina podatkov v desetinah terabajtov;
- Obremenitev več kot 2 milijona operacij na uro;
- Pomen - poslovno kritičen.
Hkrati na naši strani ni bilo skladišča izvorne kode. Nasploh. Dokumentacija je obstajala, vendar so bila vsa ključna znanja in kompetence na strani zunanje organizacije.
Razvoj sistema smo začeli obvladovati skoraj iz nič, ob upoštevanju njegovih lastnosti in nizke razširjenosti. Začetek oktobra 2018:
- Preučil dokumentacijo in osnove generiranja kode;
- Preučili smo kratek tečaj o razvoju, ki smo ga prejeli od prodajalca;
- Obvladati začetne razvojne veščine;
- Sestavili smo priročnik za usposabljanje novih članov ekipe;
- Dogovorili smo se, da vključimo ekipo v "bojni" način;
- Odpravljena težava s kontrolo kakovosti kode;
- Organizirali smo stojnico za razvoj.
Tri mesece smo razvijali strokovno znanje in se poglabljali v sistem, od začetka leta 2019 pa se je hišni razvoj začel premikati v svetlo prihodnost, včasih s težavo, a samozavestno in ciljno.
Selitev repozitorija in samodejni testi
Prva naloga DevOps je repozitorij. Hitro smo se dogovorili o zagotavljanju dostopa, vendar je bila potrebna migracija iz trenutnega SVN z eno trunk vejo na naš ciljni Git s prehodom na model več vej in razvojem Git Flow. Imamo tudi 2 ekipi z lastno infrastrukturo in del ekipe prodajalca v tujini. Moral sem živeti z dvema Gitoma in zagotoviti sinhronizacijo. V takih razmerah je bilo to manjše od dveh zla.
Selitev repozitorija je bila večkrat odložena, dokončana je bila šele aprila s pomočjo kolegov iz prve bojne črte. Z Git Flow smo se odločili, da bomo stvari za začetek poenostavili in se odločili za klasično shemo s hitrimi popravki, razvojem in izdajo. Odločili so se, da bodo opustili master (aka prod-like). V nadaljevanju bomo pojasnili, zakaj se je ta možnost za nas izkazala za optimalno. Kot delavec je bil uporabljen zunanji repozitorij, ki pripada prodajalcu in je skupen za dve ekipi. Sinhroniziral se je z notranjim repozitorijem po urniku. Zdaj je bilo z Gitom in Gitlabom mogoče avtomatizirati procese.
Vprašanje samodejnih testov je bilo presenetljivo enostavno rešeno - dobili smo že pripravljen okvir. Glede na posebnosti sistema je bil klic ločene operacije razumljiv del poslovnega procesa in je hkrati služil kot test enote. Preostala je le še priprava testnih podatkov in nastavitev želenega vrstnega reda priklica skript in vrednotenja rezultatov. Ko se je izpolnil seznam scenarijev, oblikovan na podlagi statistike delovanja, kritičnosti procesov in obstoječe regresijske metodologije, so se začeli pojavljati avtomatski testi. Zdaj lahko začnemo graditi plinovod.
Kako je bilo: model pred avtomatizacijo
Obstoječi model izvedbenega procesa je posebna zgodba. Vsaka sprememba je bila ročno prenesena kot ločen inkrementalni namestitveni paket. Sledila je ročna registracija v Jira in ročna namestitev v okolja. Pri posameznih paketih je bilo videti vse jasno, pri pripravi izdaje pa je bilo bolj zapleteno.
Montaža je potekala na ravni posameznih dobav, ki so bile samostojni objekti. Vsaka sprememba je nova dobava. Med drugim je bilo 60–70 paketom glavne sestave izdaje dodanih 10–15 tehničnih različic - različice, pridobljene ob dodajanju ali izključitvi nečesa iz izdaje in odražajo spremembe v prodaji zunaj izdaj.
Objekti v dobavah so se med seboj prekrivali, zlasti v izvedljivi kodi, ki je bila manj kot napol unikatna. Bilo je veliko odvisnosti tako od že nameščene kode kot od tiste, katere namestitev je bila šele načrtovana.
Za pridobitev zahtevane različice kode je bilo potrebno strogo upoštevati vrstni red namestitve, med katerim so bili objekti večkrat fizično prepisani, približno 10–12-krat.
Po namestitvi serije paketov sem moral ročno slediti navodilom za inicializacijo nastavitev. Izdajo je sestavil in namestil prodajalec. Sestava izdaje je bila pojasnjena skoraj pred trenutkom izvajanja, kar je pomenilo ustvarjanje paketov za "ločevanje". Posledično se je znaten del zalog selil iz izdaje v izdajo s svojim lastnim repom »odklopov«.
Zdaj je jasno, da s tem pristopom - sestavljanjem uganke za izdajo na ravni paketa - ena glavna veja ni imela praktičnega pomena. Namestitev v proizvodnji je trajala od ene in pol do dveh ur ročnega dela. Dobro je, da je vsaj na inštalaterskem nivoju določen vrstni red obdelave objektov: polja in strukture so vneseni pred podatki zanje in postopki. Vendar je to delovalo le v ločenem paketu.
Logični rezultat tega pristopa so bile obvezne napake v namestitvi v obliki ukrivljenih različic objektov, nepotrebne kode, manjkajočih navodil in neupoštevanih medsebojnih vplivov objektov, ki so bili po izdaji mrzlično odpravljeni.
Prve posodobitve: potrditev sestave in dostave
Avtomatizacija se je začela s prenosom kode skozi cev po tej poti:
- Prevzem končane pošiljke iz skladišča;
- Namestite ga v namensko okolje;
- Izvedite samodejne teste;
- Ocenite rezultat namestitve;
- Pokličite naslednji cevovod na strani ukaza za testiranje.
Naslednji cevovod bi moral registrirati nalogo v Jiri in počakati, da se ukazi razdelijo v izbrane testne zanke, ki so odvisne od časovnega razporeda izvedbe naloge. Sprožilec - pismo o pripravljenosti za dostavo na dani naslov. To je bila seveda očitna bergla, a nekje sem moral začeti. Maja 2019 se je začel prenos kode s pregledi naših okolij. Proces se je začel, ostalo je le, da ga spravimo v dostojno obliko:
- Vsaka sprememba se izvede v ločeni veji, ki ustreza namestitvenemu paketu in se združi v ciljno glavno vejo;
- Sprožilec zagona cevovoda je pojav nove objave v glavni veji prek zahteve za spajanje, ki jo zaprejo vzdrževalci iz notranje ekipe;
- Repozitoriji se sinhronizirajo vsakih pet minut;
- Začne se sestavljanje namestitvenega paketa - z uporabo asemblerja, ki ga dobite od prodajalca.
Po tem so že obstajali koraki za preverjanje in prenos kode, za zagon cevi in montažo na naši strani.
Ta možnost je bila predstavljena julija. Težave pri prehodu so povzročile nekaj nezadovoljstva med prodajalcem in prvo linijo, vendar nam je v naslednjem mesecu uspelo odstraniti vse robove in vzpostaviti proces med ekipami. Zdaj imamo montažo s prevzemom in dostavo.
Avgusta nam je uspelo zaključiti prvo namestitev ločenega paketa v produkciji z našim pipeline-om, od septembra pa so vse namestitve posameznih neizdajnih paketov brez izjeme potekale preko našega orodja CD. Poleg tega nam je uspelo doseči delež internih opravil v 40% sestave izdaje z manjšo ekipo od prodajalca - to je nedvomno uspeh. Najresnejša naloga je ostala - sestaviti in namestiti izdajo.
Končna rešitev: kumulativni namestitveni paketi
Povsem dobro smo razumeli, da je skriptiranje navodil prodajalca tako ali tako avtomatizacija; morali smo ponovno razmisliti o samem procesu. Rešitev je bila očitna - zbrati kumulativno ponudbo iz izdajne veje z vsemi predmeti zahtevanih različic.
Začeli smo z dokazom koncepta: ročno smo sestavili izdajni paket glede na vsebino pretekle izvedbe in ga namestili v naša okolja. Vse se je izšlo, koncept se je izkazal za izvedljivega. Nato smo rešili težavo s skriptiranjem inicializacijskih nastavitev in njihovo vključitvijo v objavo. Pripravili smo nov paket in ga preizkusili v testnih okoljih v okviru posodobitve contour. Namestitev je bila uspešna, čeprav s številnimi pripombami izvajalske ekipe. Toda glavna stvar je, da smo dobili zeleno luč za začetek proizvodnje v novembrski izdaji z našo montažo.
Ostalo je še nekaj več kot mesec dni, zato so ročno izbrane zaloge jasno nakazovale, da se čas izteka. Odločili so se, da bodo gradnjo naredili iz izdajne veje, a zakaj bi jo morali ločiti? Nimamo izdelka, podobnega Produ, in obstoječe veje niso dobre - veliko je nepotrebne kode. Nujno moramo zmanjšati prod-like, in to je več kot tri tisoč potrditev. Ročno sestavljanje sploh ne pride v poštev. Skicirali smo skript, ki teče skozi dnevnik namestitve izdelka in zbira potrditve za vejo. Tretjič je delovalo pravilno in po "končanju z datoteko" je bila veja pripravljena.
Za namestitveni paket smo napisali svoj graditelj in ga končali v enem tednu. Nato smo morali spremeniti namestitveni program iz osnovne funkcionalnosti sistema, saj je odprtokoden. Po vrsti preverjanj in sprememb je bil rezultat ocenjen kot uspešen. Medtem se je oblikovala sestava izdaje, za pravilno namestitev katere je bilo potrebno preskusno vezje uskladiti s proizvodnim, za to pa je bil napisan ločen skript.
Seveda je bilo veliko komentarjev o prvi namestitvi, a na splošno je koda delovala. In po približno tretji namestitvi je vse začelo izgledati dobro. Nadzor sestave in nadzor različic objektov smo spremljali ločeno v ročnem načinu, kar je bilo na tej stopnji povsem upravičeno.
Dodaten izziv je bilo veliko število neobjav, ki jih je bilo treba upoštevati. Toda z vejo, podobno Produ, in Rebase je naloga postala pregledna.
Prvič, hitro in brez napak
K izdaji smo pristopili z optimističnim odnosom in več kot ducatom uspešnih namestitev na različnih dirkališčih. Toda dobesedno dan pred iztekom roka se je izkazalo, da prodajalec ni dokončal dela za pripravo izdaje za namestitev na sprejet način. Če iz nekega razloga naša zgradba ne deluje, bo izdaja motena. Še več, z našim trudom, kar je še posebej neprijetno. Nismo imeli možnosti za umik. Zato smo razmislili o alternativnih možnostih, pripravili akcijske načrte in začeli z montažo.
Presenetljivo je, da se je celotna izdaja, sestavljena iz več kot 800 predmetov, začela pravilno, prvič in v samo 10 minutah. Eno uro smo pregledovali dnevnike in iskali napake, vendar jih nismo našli.
Ves naslednji dan je bila v klepetu o izdaji tišina: nobenih težav z implementacijo, ukrivljenih različic ali »neprimerne« kode. Bilo je celo nekako nerodno. Kasneje so se pojavile nekatere pripombe, vendar je bilo v primerjavi z drugimi sistemi in dosedanjimi izkušnjami njihovo število in prioriteta opazno manjša.
Dodaten učinek kumulativnega učinka je bil dvig kakovosti montaže in testiranja. Zaradi večkratnih namestitev polne izdaje so bile napake pri gradnji in napake pri uvajanju ugotovljene pravočasno. Testiranje v konfiguracijah polne izdaje je omogočilo dodatno identifikacijo napak v medsebojnem vplivu objektov, ki se med inkrementalnimi namestitvami niso pojavile. Vsekakor je bil uspeh, zlasti glede na naš 57-odstotni prispevek k izdaji.
Rezultati in zaključki
V manj kot letu dni nam je uspelo:
- Zgradite polnopravni notranji razvoj z uporabo eksotičnega sistema;
- Odpravite kritično odvisnost od prodajalca;
- Zagon CI/CD za zelo neprijazno zapuščino;
- Dvigniti implementacijske procese na novo tehnično raven;
- Znatno skrajša čas uvajanja;
- Bistveno zmanjšati število napak pri implementaciji;
- Samozavestno se razglasite za vodilnega razvojnega strokovnjaka.
Seveda je večina opisanega videti kot čista bedarija, vendar so to lastnosti sistema in procesne omejitve, ki obstajajo v njem. Trenutno so spremembe vplivale na izdelke in storitve IS Profile (glavni računi, plastične kartice, varčevalni računi, escrow, gotovinska posojila), potencialno pa je pristop mogoče uporabiti za katerikoli IS, za katerega je zastavljena naloga implementacije DevOps praks. Kumulativni model je mogoče varno ponoviti za naslednje izvedbe (vključno s tistimi, ki niso izdane) iz številnih dobav.
Vir: www.habr.com