DevOps prakse rade. U to smo se i sami uvjerili kada smo 10 puta smanjili vrijeme instalacije izdanja. U sistemu FIS Profile, koji koristimo u VTB-u, instalacija sada traje 90 minuta, a ne 10. Vrijeme izrade izdanja je smanjeno sa dvije sedmice na dva dana. Broj upornih nedostataka u implementaciji pao je na gotovo minimum. Da bismo se maknuli od “manualnog rada” i eliminirali ovisnost o prodavaču, morali smo raditi sa štakama i pronaći neočekivana rješenja. Ispod reza je detaljna priča o tome kako smo izgradili punopravni interni razvoj.
Prolog: DevOps je filozofija
Tokom protekle godine uradili smo dosta posla na organizaciji internog razvoja i implementacije DevOps praksi u VTB:
- Izgradili smo interne razvojne procese za 12 sistema;
- Pokrenuli smo 15 cjevovoda, od kojih su četiri dovedena u proizvodnju;
- Automatizirano 1445 testnih scenarija;
- Uspješno smo implementirali niz izdanja koje su pripremili interni timovi.
Jedan od najtežih za organizaciju internog razvoja i implementacije DevSecOps praksi pokazao se FIS Profile sistem - maloprodajni procesor proizvoda na nerelacionom DBMS-u. Ipak, bili smo u mogućnosti da izgradimo razvoj, pokrenemo cevovod, instaliramo pojedinačne pakete bez izdanja na proizvod i naučimo kako da sastavljamo izdanja. Zadatak nije bio lak, ali zanimljiv i bez očiglednih ograničenja u implementaciji: evo sistema - potrebno je izgraditi interni 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 prihvatljiv nivo kvaliteta od kodnog tima bez grubih nedostataka;
- Integriramo se u postojeće procese što je više moguće;
- Za prijenos koda između očitih faza, isječemo cjevovod i guramo jedan od njegovih krajeva u nastavak.
Za to vrijeme razvojni tim potrebne veličine mora razviti vještine i povećati udio svog doprinosa izdanjima na prihvatljiv nivo. I to je to, možemo smatrati da je zadatak završen.
Čini se da je ovo potpuno energetski efikasan put do traženog rezultata: evo DevOps-a, evo metrike performansi tima, evo akumulirane stručnosti... Ali u praksi smo dobili još jednu potvrdu da je DevOps ipak filozofija , a ne "prikačen na gitlab proces, ansible, nexus i dalje na listi."
Nakon što smo još jednom analizirali akcioni plan, shvatili smo da u sebi gradimo neku vrstu outsourcing dobavljača. Stoga je gore opisanom algoritmu dodat 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 ovo je put ideološki ispravnog razvoja.
Gdje počinje unutrašnji razvoj?
To nije bio najprijateljskiji sistem za rad. Arhitektonski, to je bio jedan veliki nerelacioni DBMS, koji se sastojao od mnogo zasebnih izvršnih objekata (skripte, procedure, grupe itd.), koji su se pozivali po potrebi, a radio je po principu crne kutije: prima zahtev i izdaje odgovor. Ostale poteškoće koje treba napomenuti su:
- Egzotični jezik (MUMPS);
- Konzolni interfejs;
- Nedostatak integracije sa popularnim alatima i okvirima za automatizaciju;
- Obim podataka u desetinama terabajta;
- Opterećenje od preko 2 miliona operacija po satu;
- Značaj - poslovno-kritičan.
U isto vrijeme, na našoj strani nije bilo spremišta izvornog koda. Uopšte. Dokumentacija je postojala, ali sva ključna znanja i kompetencije su bile na strani eksterne organizacije.
Počeli smo savladavati razvoj sistema gotovo od nule, uzimajući u obzir njegove karakteristike i nisku distribuciju. Započeto u oktobru 2018:
- Proučavao dokumentaciju i osnove generisanja koda;
- Proučili smo kratki kurs o razvoju koji smo dobili od dobavljača;
- Ovladao početnim razvojnim vještinama;
- Sastavili smo priručnik za obuku za nove članove tima;
- Dogovorili smo se da uključimo tim u “borbeni” mod;
- Rešen problem sa kontrolom kvaliteta koda;
- Organizirali smo štand za razvoj.
Proveli smo tri mjeseca razvijajući stručnost i uranjajući se u sistem, a od početka 2019. godine, inhouse razvoj je krenuo ka svijetloj budućnosti, ponekad teško, ali samouvjereno i ciljano.
Migracija spremišta i autotestovi
Prvi DevOps zadatak je spremište. Brzo smo se dogovorili oko obezbeđivanja pristupa, ali je bilo potrebno migrirati sa trenutnog SVN-a sa jednom granom stabla na naš ciljni Git sa prelaskom na model nekoliko grana i razvojem Git Flow-a. Takođe imamo 2 tima sa sopstvenom infrastrukturom, plus deo tima dobavljača u inostranstvu. Morao sam živjeti sa dva Gita i osigurati sinhronizaciju. U takvoj situaciji, to je bilo manje od dva zla.
Migracija repozitorija je više puta odlagana, a završena je tek u aprilu, uz pomoć kolega sa prve linije fronta. Uz Git Flow, odlučili smo da stvari za početak budu jednostavne i odlučili smo se na klasičnu shemu s hitnim popravkom, razvojem i izdavanjem. Odlučili su da napuste master (aka prod-like). U nastavku ćemo objasniti zašto se ova opcija pokazala optimalnom za nas. Eksterno spremište koje pripada dobavljaču, zajedničko za dva tima, korišteno je kao radnik. Sinhronizirao se sa internim spremištem prema rasporedu. Sada je sa 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 specifičnosti sistema, pozivanje posebne operacije bio je razumljiv dio poslovnog procesa i istovremeno je služio kao jedinični test. Ostalo je samo pripremiti testne podatke i postaviti željeni redoslijed pozivanja skripti i evaluacije rezultata. Kako se popunjavala lista scenarija, formirana na osnovu statistike rada, kritičnosti procesa i postojeće metodologije regresije, počeli su da se pojavljuju automatski testovi. Sada možemo početi sa izgradnjom gasovoda.
Kako je bilo: model prije automatizacije
Postojeći model procesa implementacije je posebna priča. Svaka modifikacija je ručno prebačena kao poseban inkrementalni instalacijski paket. Zatim je uslijedila ručna registracija u Jira i ručna instalacija u okruženjima. Za pojedinačne pakete sve je izgledalo jasno, ali s pripremom izdanja stvari su bile složenije.
Montaža je vršena na nivou pojedinačnih isporuka, koje su bile samostalni objekti. Svaka promjena je nova isporuka. Između ostalog, 60-70 tehničkih verzija dodano je u 10-15 paketa sastava glavnog izdanja - verzije dobivene dodavanjem ili isključivanjem nečega iz izdanja i odražavanjem promjena u prodaji izvan izdanja.
Objekti unutar isporuka su se međusobno preklapali, posebno u izvršnom kodu, koji je bio manje od pola jedinstven. Bilo je mnogo zavisnosti kako od već instaliranog koda tako i od onog čija je instalacija upravo planirana.
Da bi se dobila potrebna verzija koda, bilo je potrebno striktno pratiti redosled instalacije, tokom kojeg su objekti fizički prepisani mnogo puta, nekih 10-12 puta.
Nakon instaliranja serije paketa, morao sam ručno slijediti upute da inicijaliziram postavke. Izdanje je sastavio i instalirao prodavac. Sastav izdanja je pojašnjen gotovo prije trenutka implementacije, što je podrazumijevalo stvaranje paketa za „decoupling“. Kao rezultat toga, značajan dio zaliha se kretao od izdanja do izdanja s vlastitim repom „decouplinga“.
Sada je jasno da sa ovim pristupom - sastavljanjem slagalice za oslobađanje na nivou paketa - jedna glavna grana nije imala praktično značenje. Instalacija u proizvodnji trajala je od sat i po do dva sata ručnog rada. Dobro je da je barem na razini instalatera specificiran redoslijed obrade objekata: polja i strukture su unesene prije podataka za njih i procedura. Međutim, ovo je funkcioniralo samo unutar zasebnog paketa.
Logičan rezultat ovakvog pristupa bili su obavezni instalacijski nedostaci u vidu iskrivljenih verzija objekata, nepotrebnog koda, nedostajućih instrukcija i neuračunatih međusobnih uticaja objekata, koji su grozničavo eliminisani nakon puštanja.
Prva ažuriranja: obavezna montaža i isporuka
Automatizacija je započela prijenosom koda kroz cijev duž ove rute:
- Gotovu isporuku preuzeti iz skladišta;
- Instalirajte ga u namjensko okruženje;
- Pokreni autotestove;
- Procijenite rezultat instalacije;
- Pozovite sljedeći cjevovod sa strane naredbe za testiranje.
Sljedeći cjevovod bi trebao registrirati zadatak u Jira i čekati da se komande distribuiraju odabranim petljama za testiranje, koje zavise od vremena implementacije zadatka. Trigger - pismo o spremnosti za isporuku na datu adresu. Ovo je, naravno, bila očigledna štaka, ali morao sam negdje početi. U maju 2019. počeo je prijenos koda provjerama naših okruženja. Proces je počeo, ostaje samo da se dovede u pristojan oblik:
- Svaka modifikacija se izvodi u posebnoj grani, koja odgovara instalacijskom paketu i spaja se u ciljnu glavnu granu;
- Okidač pokretanja cjevovoda je pojava novog urezivanja u glavnoj grani putem zahtjeva za stapanjem, koji zatvaraju održavači iz internog tima;
- Spremišta se sinhronizuju jednom svakih pet minuta;
- Pokreće se montaža instalacionog paketa - pomoću asemblera dobijenog od dobavljača.
Nakon ovoga, već su postojali koraci za provjeru i prijenos koda, za pokretanje cijevi i sklapanje na našoj strani.
Ova opcija je pokrenuta u julu. Poteškoće tranzicije dovele su do određenog nezadovoljstva među dobavljačima i linijom fronta, ali smo u narednih mjesec dana uspjeli ukloniti sve grube ivice i uspostaviti proces među timovima. Sada imamo montažu po obavezi i isporuku.
U kolovozu smo uspjeli dovršiti prvu instalaciju zasebnog paketa u produkciji pomoću našeg pipeline-a, a od rujna su sve instalacije pojedinačnih paketa bez iznimke vršene preko našeg CD alata. Osim toga, uspjeli smo postići udio domaćih 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 instrukcija dobavljača tako-tako automatizacija; morali smo ponovo razmisliti o samom procesu. Rješenje je bilo očigledno - prikupiti kumulativnu zalihu iz grane izdanja sa svim objektima potrebnih verzija.
Počeli smo s dokazom koncepta: ručno smo sastavili paket izdanja u skladu sa sadržajem prethodne 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 uključivanja ih u urezivanje. Pripremili smo novi paket i testirali ga u okruženjima za testiranje kao dio ažuriranja konture. Instalacija je bila uspješna, iako uz širok spektar komentara implementacionog tima. Ali glavna stvar je da smo dobili zeleno svjetlo da krenemo u proizvodnju u novembarskom izdanju sa našim sklopom.
Pošto je preostalo nešto više od mjesec dana, ručno birane zalihe jasno su nagovijestile da vrijeme ističe. Odlučili su da naprave build od grane izdanja, ali zašto bi je trebalo odvojiti? Nemamo Prod-like, a postojeće grane nisu dobre - ima puno nepotrebnog koda. Hitno moramo smanjiti prod-lajkove, a ovo je preko tri hiljade urezivanja. Ručno sastavljanje uopće nije opcija. Skicirali smo skriptu koja prolazi kroz dnevnik instalacije proizvoda i prikuplja urezivanje u granu. Treći put je proradilo kako treba, i nakon „završetka sa fajlom“ grana je bila spremna.
Napisali smo sopstveni builder za instalacioni paket i završili ga za nedelju dana. Zatim smo morali da modifikujemo instalater iz osnovne funkcionalnosti sistema, pošto je otvorenog koda. Nakon niza provjera i modifikacija, rezultat se smatra uspješnim. U međuvremenu se oblikovala kompozicija izdanja, za čiju je ispravnu instalaciju bilo potrebno uskladiti testno kolo s proizvodnim, a za to je napisan poseban skript.
Naravno, bilo je dosta komentara o prvoj instalaciji, ali generalno kod je funkcionirao. I nakon otprilike treće instalacije sve je počelo izgledati dobro. Kontrola kompozicije i kontrola verzije objekata praćeni su odvojeno u ručnom režimu, što je u ovoj fazi bilo sasvim opravdano.
Dodatni izazov je bio veliki broj nepuštanja na slobodu koja je morala biti uzeta u obzir. Ali sa granom nalik na Prod i Rebaseom, zadatak je postao transparentan.
Prvi put, brzo i bez grešaka
Izdanju smo pristupili s optimističnim stavom i više od deset uspješnih instalacija na različitim krugovima. No, bukvalno dan prije isteka roka, ispostavilo se da dobavljač nije završio posao pripreme izdanja za instalaciju na prihvaćen način. Ako iz nekog razloga naša izgradnja ne radi, izdanje će biti poremećeno. Štaviše, našim trudom, što je posebno neprijatno. Nismo imali načina da se povučemo. Stoga smo razmislili o alternativnim opcijama, pripremili akcione planove i poč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 dnevnike tražeći greške, ali ih nismo pronašli.
Cijeli sljedeći dan vladala je tišina u razgovoru o izdanju: nije bilo problema s implementacijom, pogrešnih verzija ili "neprikladnog" koda. Čak je bilo nekako i nezgodno. Kasnije su se pojavili neki komentari, ali u poređenju sa drugim sistemima i prethodnim iskustvom, njihov broj i prioritet su bili znatno manji.
Dodatni efekat kumulativnog efekta bio je povećanje kvaliteta montaže i testiranja. Zbog višestrukih instalacija punog izdanja, na vrijeme su identificirani nedostaci u izradi i implementaciji. Testiranje u konfiguracijama potpunog izdanja omogućilo je da se dodatno identificiraju nedostaci u međusobnom utjecaju objekata koji se nisu pojavili tijekom inkrementalnih instalacija. To je definitivno bio uspjeh, posebno s obzirom na naš doprinos izdanju od 57%.
Rezultati i zaključci
Za manje od godinu dana uspjeli smo:
- Izgradite potpuni interni razvoj koristeći egzotični sistem;
- Eliminišite kritičnu zavisnost od dobavljača;
- Pokrenite CI/CD za vrlo neprijateljsko naslijeđe;
- Podići procese implementacije na novi tehnički nivo;
- Značajno smanjiti vrijeme implementacije;
- Značajno smanjiti broj grešaka u implementaciji;
- Sa sigurnošću se deklarirajte kao vodeći stručnjak za razvoj.
Naravno, mnogo toga što je opisano izgleda kao potpuno sranje, ali ovo su karakteristike sistema i ograničenja procesa koja postoje u njemu. Trenutno su promjene uticale na proizvode i usluge IS Profile (master račune, plastične kartice, štedne račune, escrow, gotovinske kredite), ali potencijalno se pristup može primijeniti na bilo koji IS za koji je postavljen zadatak implementacije DevOps praksi. Kumulativni model se može bezbedno replicirati za naknadne implementacije (uključujući one bez izdavanja) iz mnogih isporuka.
izvor: www.habr.com