DevOps prakse funkcioniraju. U to smo se i sami uvjerili kada smo smanjili vrijeme instalacije izdanja za 10 puta. U sustavu FIS Profile, koji koristimo u VTB-u, instalacija sada traje 90 minuta umjesto 10. Vrijeme izrade izdanja smanjeno je s dva tjedna na dva dana. Broj trajnih nedostataka u implementaciji pao je gotovo na minimum. Kako bismo pobjegli od "fizičkog rada" i eliminirali ovisnost o dobavljaču, morali smo raditi sa štakama i pronaći neočekivana rješenja. Ispod presjeka je detaljna priča o tome kako smo izgradili puni interni razvoj.
Prolog: DevOps je filozofija
Tijekom prošle godine puno smo radili na organizaciji internog razvoja i implementacije DevOps praksi u VTB-u:
- Izgradili smo interne razvojne procese za 12 sustava;
- Pustili smo 15 cjevovoda, od kojih su četiri puštena u proizvodnju;
- Automatizirano 1445 testnih scenarija;
- Uspješno smo implementirali niz izdanja koje su pripremili interni timovi.
Ispostavilo se da je jedan od najtežih za organiziranje internog razvoja i implementacije DevSecOps praksi sustav FIS Profile - procesor maloprodajnih proizvoda na nerelacijskom DBMS-u. Usprkos tome, uspjeli smo izgraditi razvoj, pokrenuti cjevovod, instalirati pojedinačne pakete bez izdanja na proizvod i naučili kako sastaviti izdanja. Zadatak nije bio lak, ali zanimljiv i bez očitih ograničenja u implementaciji: evo sustava - trebate izgraditi in-house razvoj. Jedini uvjet je korištenje CD-a prije produktivnog okruženja.
U početku se algoritam implementacije činio jednostavnim i jasnim:
- Razvijamo početnu razvojnu ekspertizu i postižemo prihvatljivu razinu kvalitete od kodnog tima bez velikih nedostataka;
- Integriramo se u postojeće procese što je više moguće;
- Za prijenos koda između očiglednih faza, režemo cjevovod i guramo jedan njegov kraj u nastavak.
Tijekom tog vremena, razvojni tim potrebne veličine mora razviti vještine i povećati udio svog doprinosa izdanjima na prihvatljivu razinu. I to je to, možemo smatrati da je zadatak obavljen.
Čini se da je to potpuno energetski učinkovit put do traženog rezultata: evo DevOpsa, evo metrike učinka tima, evo akumulirane ekspertize... Ali u praksi smo dobili još jednu potvrdu da je DevOps ipak filozofija , a ne "pripojeno gitlab procesu, ansibleu, nexusu i niže na popisu."
Nakon još jedne analize akcijskog plana, shvatili smo da unutar sebe gradimo svojevrsnog outsourcing dobavljača. Stoga je gore opisanom algoritmu dodan reinženjering procesa, kao i razvoj stručnosti duž cijelog razvojnog puta kako bi se postigla vodeća uloga u ovom procesu. Nije najlakša opcija, ali to je put ideološki ispravnog razvoja.
Gdje počinje razvoj unutar kuće?
To nije bio najprijateljskiji sustav za rad. Arhitektonski je to bio jedan veliki nerelacijski DBMS, koji se sastojao od mnogo odvojenih izvršnih objekata (skripti, procedura, paketa itd.), koji su se pozivali po potrebi, a radio je na principu crne kutije: prima zahtjev i izdaje odgovor. Ostale poteškoće vrijedne pažnje uključuju:
- Egzotični jezik (MUMPS);
- Sučelje konzole;
- Nedostatak integracije s popularnim alatima i okvirima za automatizaciju;
- Količina podataka u desecima terabajta;
- Opterećenje od preko 2 milijuna operacija po satu;
- Značaj - poslovno kritičan.
Istodobno, s naše strane nije bilo repozitorija izvornog koda. Uopće. Dokumentacija je postojala, ali su sva ključna znanja i kompetencije bile na strani vanjske organizacije.
Počeli smo svladavati razvoj sustava gotovo od nule, uzimajući u obzir njegove karakteristike i nisku distribuciju. Pokrenuto u listopadu 2018.:
- Proučavao dokumentaciju i osnove generiranja koda;
- Proučavali smo kratki tečaj o razvoju koji smo dobili od dobavljača;
- Savladane početne razvojne vještine;
- Sastavili smo priručnik za obuku novih članova tima;
- Dogovorili smo se uključiti tim u "borbeni" mod;
- Riješen problem s kontrolom kvalitete koda;
- Organizirali smo štand za razvoj.
Proveli smo tri mjeseca razvijajući ekspertizu i uživljavajući se u sustav, a od početka 2019. inhouse development krenuo je u svijetlu budućnost, ponekad teško, ali samouvjereno i ciljano.
Migracija repozitorija i autotestovi
Prvi DevOps zadatak je spremište. Brzo smo se dogovorili oko omogućavanja pristupa, no bilo je potrebno migrirati s trenutnog SVN-a s jednim trunk ogrankom na naš ciljni Git uz prelazak na model više ogranaka i razvoj Git Flowa. Također imamo 2 tima s vlastitom infrastrukturom, plus dio tima dobavljača u inozemstvu. Morao sam živjeti s dva Gita i osigurati sinkronizaciju. U takvoj situaciji to je bilo manje od dva zla.
Migracija repozitorija se više puta odgađala, a dovršena je tek u travnju, uz pomoć kolega s prve crte. S Git Flowom odlučili smo stvari za početak učiniti jednostavnima i odlučili smo se za klasičnu shemu s hitnim popravkom, razvojem i izdavanjem. Odlučili su napustiti master (aka prod-like). U nastavku ćemo objasniti zašto se ova opcija pokazala optimalnom za nas. Vanjski repozitorij koji pripada dobavljaču, zajednički za dva tima, korišten je kao radnik. Sinkronizirao se s internim spremištem prema rasporedu. Sada je s Gitom i Gitlabom bilo moguće automatizirati procese.
Pitanje autotestova riješeno je iznenađujuće lako - dobili smo gotov okvir. Uzimajući u obzir posebnosti sustava, pozivanje zasebne operacije bilo je razumljiv dio poslovnog procesa te je ujedno služilo i kao jedinični test. Preostalo je samo pripremiti testne podatke i postaviti željeni redoslijed pozivanja skripti i evaluacije rezultata. Kako se popunjavao popis scenarija, formiran na temelju statistike rada, kritičnosti procesa i postojeće regresijske metodologije, počeli su se pojavljivati automatski testovi. Sada bismo mogli početi graditi plinovod.
Kako je bilo: model prije automatizacije
Postojeći model procesa implementacije je posebna priča. Svaka izmjena je ručno prenesena kao zasebni inkrementalni instalacijski paket. Zatim je uslijedila ručna registracija u Jiri i ručna instalacija u okruženjima. Za pojedinačne pakete sve je izgledalo jasno, ali s pripremom izdanja stvari su bile kompliciranije.
Montaža se odvijala na razini pojedinačnih isporuka koje su bile samostalni objekti. Svaka promjena je nova isporuka. Između ostalog, 60-70 tehničkih verzija dodano je na 10-15 paketa glavnog sastava izdanja - verzije dobivene dodavanjem ili isključivanjem nečega iz izdanja i odražavaju promjene u prodaji izvan izdanja.
Objekti unutar isporuka preklapali su se jedni s drugima, osobito u izvršnom kodu, koji je bio manje od polovice jedinstven. Bilo je mnogo ovisnosti kako o već instaliranom kodu tako i o onom čija je instalacija tek planirana.
Da bi se dobila potrebna verzija koda, bilo je potrebno striktno slijediti redoslijed instalacije, pri čemu su objekti fizički prepisani mnogo puta, nekih 10-12 puta.
Nakon instaliranja serije paketa, morao sam ručno slijediti upute za pokretanje postavki. Izdanje je sastavio i instalirao dobavljač. Sastav izdanja razjašnjen je gotovo prije trenutka implementacije, što je podrazumijevalo stvaranje paketa za "odvajanje". Kao rezultat toga, značajan dio zaliha kretao se od izdanja do izdanja s vlastitim repom "odvajanja".
Sada je jasno da s ovim pristupom - sastavljanjem slagalice izdanja na razini paketa - jedna glavna grana nije imala praktično značenje. Instalacija u proizvodnji trajala je od sat i pol do dva sata ručnog rada. Dobro je da je barem na razini instalatera određen redoslijed obrade objekata: polja i strukture unesene su prije podataka za njih i postupaka. Međutim, to je funkcioniralo samo unutar zasebnog paketa.
Logičan rezultat ovakvog pristupa bili su obavezni nedostaci instalacije u obliku krivih verzija objekata, nepotrebnog koda, nedostajućih uputa i neuračunatih međusobnih utjecaja objekata, koji su grozničavo eliminirani nakon izdavanja.
Prva ažuriranja: izvršite sklapanje i isporuku
Automatizacija je započela prijenosom koda kroz cijev duž ove rute:
- Pokupite gotovu isporuku iz skladišta;
- Instalirajte ga na namjensko okruženje;
- Pokrenite automatske testove;
- Procijenite rezultat instalacije;
- Pozovite sljedeći cjevovod na strani naredbe za testiranje.
Sljedeći cjevovod trebao bi registrirati zadatak u Jiri i čekati da se naredbe distribuiraju odabranim petljama testiranja, koje ovise o vremenu implementacije zadatka. Okidač - pismo o spremnosti za dostavu na zadanu adresu. Ovo je, naravno, bila očita prepreka, ali morao sam negdje početi. U svibnju 2019. započeo je prijenos koda provjerama naših okruženja. Proces je krenuo, preostaje ga samo dovesti u pristojan oblik:
- Svaka se izmjena izvodi u zasebnoj grani, koja odgovara instalacijskom paketu i stapa se u ciljnu glavnu granu;
- Okidač za pokretanje cjevovoda je pojava novog urezivanja u glavnoj grani kroz zahtjev za spajanje, koji zatvaraju održavatelji iz internog tima;
- Spremišta se sinkroniziraju svakih pet minuta;
- Pokreće se montaža instalacijskog paketa - korištenjem asemblera dobivenog od dobavljača.
Nakon toga su već postojali koraci za provjeru i prijenos koda, za pokretanje cijevi i montažu na našoj strani.
Ova je opcija pokrenuta u srpnju. Poteškoće prijelaza rezultirale su određenim nezadovoljstvom dobavljača i prve linije, ali tijekom sljedećeg mjeseca uspjeli smo ukloniti sve grubosti i uspostaviti proces među timovima. Sada imamo montažu preuzimanjem i isporukom.
U kolovozu smo uspjeli dovršiti prvu instalaciju zasebnog paketa u produkciji koristeći naš pipeline, a od rujna, bez iznimke, sve instalacije pojedinačnih paketa bez izdanja obavljaju se putem našeg CD alata. Osim toga, uspjeli smo postići udio inhouse zadataka u 40% sastava izdanja s manjim timom od dobavljača - ovo je definitivan uspjeh. Ostao je najozbiljniji zadatak - sastaviti i instalirati izdanje.
Konačno rješenje: kumulativni instalacijski paketi
Savršeno smo dobro razumjeli da je skriptiranje uputa dobavljača tako-tako automatizacija; morali smo ponovno razmisliti o samom procesu. Rješenje je bilo očito - prikupiti kumulativnu ponudu iz grane izdanja sa svim objektima potrebnih verzija.
Počeli smo s dokazom koncepta: ručno smo sastavili paket izdanja prema sadržaju prošle implementacije i instalirali ga u naša okruženja. Sve je uspjelo, koncept se pokazao održivim. Zatim smo riješili problem skriptiranja postavki inicijalizacije i njihovog uključivanja u commit. Pripremili smo novi paket i testirali ga u testnim okruženjima u sklopu ažuriranja konture. Instalacija je bila uspješna, iako uz širok raspon komentara od strane implementacijskog tima. Ali glavna stvar je da smo dobili zeleno svjetlo za početak proizvodnje u izdanju u studenom s našim sklopom.
Preostalo je nešto više od mjesec dana, a ručno odabrane zalihe jasno su davale naslutiti da vrijeme ističe. Odlučili su napraviti build iz grane izdanja, ali zašto bi to bilo odvojeno? Nemamo Prod-like, a postojeće grane nisu dobre - ima puno nepotrebnog koda. Moramo hitno smanjiti prod-lajkove, a ovo je više od tri tisuće obveza. Ručno sastavljanje uopće ne dolazi u obzir. Skicirali smo skriptu koja prolazi kroz dnevnik instalacije proizvoda i prikuplja obveze prema grani. Treći put je radilo ispravno i nakon "završetka s datotekom" grana je bila spremna.
Napisali smo vlastiti builder za instalacijski paket i završili ga za tjedan dana. Zatim smo morali modificirati instalacijski program iz osnovne funkcionalnosti sustava, budući da je open-source. Nakon niza provjera i izmjena, rezultat se smatra uspješnim. U međuvremenu se oblikovao sastav izdanja, za čiju je ispravnu ugradnju bilo potrebno uskladiti ispitni krug s proizvodnim, a za to je napisana posebna skripta.
Naravno, bilo je puno komentara o prvoj instalaciji, ali generalno je kod radio. I nakon otprilike treće instalacije sve je počelo izgledati dobro. Kontrola sastava i kontrola verzija objekata praćene su odvojeno u ručnom načinu rada, što je u ovoj fazi bilo sasvim opravdano.
Dodatni izazov bio je velik broj neobjavljivanja o kojima se moralo voditi računa. Ali s granom sličnom Prod-u i Rebaseom zadatak je postao transparentan.
Prvi put, brzo i bez greške
Izdanju smo pristupili s optimističnim stavom i više od desetak uspješnih instalacija na različitim krugovima. Ali doslovno dan prije isteka roka pokazalo se da dobavljač nije dovršio rad na pripremi izdanja za instalaciju na prihvaćeni način. Ako iz nekog razloga naša verzija ne radi, izdanje će biti prekinuto. Štoviše, našim trudom, što je posebno neugodno. Nismo imali načina da se povučemo. Stoga smo razmislili o alternativnim opcijama, pripremili akcijske planove i započeli instalaciju.
Iznenađujuće, cijelo izdanje, koje se sastoji od više od 800 objekata, počelo je ispravno, prvi put i to za samo 10 minuta. Proveli smo sat vremena provjeravajući zapisnike tražeći pogreške, ali nismo ih pronašli.
Cijeli sljedeći dan vladala je tišina u chatu o izdanju: nije bilo problema s implementacijom, krivih verzija ili "neprimjerenog" koda. Bilo je čak nekako neugodno. Kasnije su se pojavili neki komentari, ali u usporedbi s drugim sustavima i prijašnjim iskustvima, njihov broj i prioritet su osjetno manji.
Dodatni učinak kumulativnog učinka bio je povećanje kvalitete montaže i testiranja. Zbog višestrukih instalacija potpunog izdanja, nedostaci u izradi i pogreške u implementaciji identificirani su na vrijeme. Testiranje u konfiguracijama potpunog izdanja omogućilo je dodatno identificiranje nedostataka u međusobnom utjecaju objekata koji se nisu pojavili tijekom inkrementalnih instalacija. To je definitivno bio uspjeh, posebno s obzirom na naš doprinos od 57% izdanju.
Rezultati i zaključci
U manje od godinu dana uspjeli smo:
- Izgradite puni unutarnji razvoj koristeći egzotičan sustav;
- Uklonite kritičnu ovisnost o dobavljaču;
- Pokrenite CI/CD za vrlo neprijateljsko nasljeđe;
- Podići procese implementacije na novu tehničku razinu;
- Značajno smanjiti vrijeme postavljanja;
- Značajno smanjiti broj pogrešaka u implementaciji;
- Samouvjereno se deklarirajte kao vodeći stručnjak za razvoj.
Naravno, mnogo toga što je opisano izgleda kao čisto sranje, ali to su značajke sustava i ograničenja procesa koja postoje u njemu. Trenutno su promjene zahvatile proizvode i usluge IS Profile (glavni računi, plastične kartice, štedni računi, escrow, gotovinski krediti), no potencijalno se pristup može primijeniti na bilo koji IS za koji je postavljen zadatak implementacije DevOps praksi. Kumulativni model može se sigurno replicirati za sljedeće implementacije (uključujući one koje nisu objavljene) iz mnogih isporuka.
Izvor: www.habr.com