DevOps-praksis virker. Det var vi selv overbevist om, da vi reducerede installationstiden for release med 10 gange. I FIS Profile-systemet, som vi bruger hos VTB, tager installationen nu 90 minutter i stedet for 10. Release-byggetiden er faldet fra to uger til to dage. Antallet af vedvarende implementeringsfejl er faldet til næsten et minimum. For at komme væk fra "manuelt arbejde" og eliminere afhængigheden af leverandøren, var vi nødt til at arbejde med krykker og finde uventede løsninger. Under snittet er en detaljeret historie om, hvordan vi byggede en fuldgyldig intern udvikling.
Prolog: DevOps er en filosofi
I løbet af det seneste år har vi gjort en masse arbejde for at organisere den interne udvikling og implementering af DevOps-praksis hos VTB:
- Vi byggede interne udviklingsprocesser for 12 systemer;
- Vi lancerede 15 rørledninger, hvoraf fire blev bragt i produktion;
- Automatiserede 1445 testscenarier;
- Vi har med succes implementeret en række udgivelser udarbejdet af interne teams.
En af de sværeste at organisere intern udvikling og implementering af DevSecOps-praksis viste sig at være FIS Profile-systemet - en detailproduktprocessor på et ikke-relationelt DBMS. Ikke desto mindre var vi i stand til at bygge udviklingen, lancere pipeline, installere individuelle non-release-pakker på produktet og lært, hvordan man samler udgivelser. Opgaven var ikke let, men interessant og uden åbenlyse begrænsninger i implementeringen: her er systemet - du skal bygge en intern udvikling. Den eneste betingelse er at bruge cd'en før et produktivt miljø.
I starten virkede implementeringsalgoritmen enkel og klar:
- Vi udvikler indledende udviklingsekspertise og opnår et acceptabelt kvalitetsniveau fra kodeteamet uden grove defekter;
- Vi integrerer i eksisterende processer så meget som muligt;
- For at overføre kode mellem åbenlyse stadier skærer vi en rørledning og skubber en af dens ender ind i fortsættelsen.
I løbet af denne tid skal udviklingsteamet af den nødvendige størrelse udvikle færdigheder og øge andelen af sit bidrag til udgivelser til et acceptabelt niveau. Og det er det, vi kan betragte opgaven som afsluttet.
Det ser ud til, at dette er en fuldstændig energieffektiv vej til det ønskede resultat: her er DevOps, her er holdets præstationsmålinger, her er den akkumulerede ekspertise... Men i praksis fik vi endnu en bekræftelse på, at DevOps stadig handler om filosofi , og ikke "knyttet til gitlab-processen, ansible, nexus og længere nede på listen."
Efter endnu en gang at have analyseret handlingsplanen, indså vi, at vi var ved at bygge en slags outsource-leverandør i os selv. Derfor blev procesreengineering tilføjet til den ovenfor beskrevne algoritme, samt udvikling af ekspertise langs hele udviklingsruten for at opnå en ledende rolle i denne proces. Ikke den nemmeste løsning, men dette er vejen til en ideologisk korrekt udvikling.
Hvor begynder den interne udvikling?
Det var ikke det mest venlige system at arbejde med. Arkitektonisk var det én stor ikke-relationel DBMS, bestod af mange separate eksekverbare objekter (scripts, procedurer, batches osv.), som blev kaldt efter behov, og arbejdede efter princippet om en sort boks: den modtager en anmodning og udsteder et svar. Andre vanskeligheder, der er værd at bemærke, omfatter:
- Eksotisk sprog (MUMPS);
- Konsol interface;
- Manglende integration med populære automatiseringsværktøjer og rammer;
- Datavolumen i snesevis af terabyte;
- Belastning på over 2 millioner operationer i timen;
- Betydning - Forretningskritisk.
Samtidig var der ikke noget kildekodelager på vores side. Overhovedet. Der var dokumentation, men al nøgleviden og -kompetencer var på en ekstern organisations side.
Vi begyndte at mestre udviklingen af systemet næsten fra bunden under hensyntagen til dets funktioner og lave distribution. Startet i oktober 2018:
- Studerede dokumentationen og det grundlæggende i kodegenerering;
- Vi studerede det korte kursus om udvikling modtaget fra leverandøren;
- Mestrer indledende udviklingsevner;
- Vi har udarbejdet en træningsmanual til nye teammedlemmer;
- Vi blev enige om at inkludere holdet i "kamp"-tilstand;
- Løste problemet med kodekvalitetskontrol;
- Vi arrangerede en stand for udvikling.
Vi brugte tre måneder på at udvikle ekspertise og fordybe os i systemet, og fra begyndelsen af 2019 begyndte intern udvikling sin bevægelse mod en lys fremtid, nogle gange med besvær, men selvsikkert og målrettet.
Repository migration og autotests
Den første DevOps-opgave er repository. Vi blev hurtigt enige om at give adgang, men det var nødvendigt at migrere fra det nuværende SVN med en trunkgren til vores mål-Git med overgangen til en model af flere grene og udvikling af Git Flow. Vi har også 2 teams med deres egen infrastruktur, plus en del af leverandørens team i udlandet. Jeg måtte leve med to Gits og sikre synkronisering. I en sådan situation var det det mindste af to onder.
Migreringen af depotet blev gentagne gange udskudt; det blev først afsluttet i april med hjælp fra kolleger fra frontlinjen. Med Git Flow besluttede vi at holde tingene enkle til en start og slog os fast på den klassiske ordning med hotfix, udvikling og frigivelse. De besluttede at opgive master (aka prod-lignende). Nedenfor vil vi forklare, hvorfor denne mulighed viste sig at være optimal for os. Et eksternt lager tilhørende leverandøren, fælles for to teams, blev brugt som arbejder. Det synkroniserede med det interne lager i henhold til en tidsplan. Nu med Git og Gitlab var det muligt at automatisere processer.
Spørgsmålet om autotest blev løst overraskende nemt - vi fik et færdigt rammeværk. Under hensyntagen til systemets ejendommeligheder var det at kalde en separat operation en forståelig del af forretningsprocessen og fungerede samtidig som en enhedstest. Det eneste, der var tilbage, var at forberede testdataene og indstille den ønskede rækkefølge for at kalde scripts og evaluere resultaterne. Efterhånden som listen over scenarier, dannet på grundlag af driftsstatistik, kritikaliteten af processer og den eksisterende regressionsmetodologi, blev udfyldt, begyndte automatiske test at dukke op. Nu kunne vi begynde at bygge rørledningen.
Sådan var det: modellen før automatisering
Den eksisterende model for implementeringsprocessen er en separat historie. Hver modifikation blev manuelt overført som en separat trinvis installationspakke. Dernæst kom manuel registrering i Jira og manuel installation på miljøer. For individuelle pakker så alt klart ud, men med forberedelsen af udgivelsen var tingene mere komplicerede.
Montering blev udført på niveau med individuelle leverancer, som var selvstændige objekter. Enhver ændring er en ny levering. Blandt andet blev der tilføjet 60-70 tekniske versioner til de 10-15 pakker af hovedudgivelsessammensætningen - versioner opnået ved tilføjelse eller udelukkelse af noget fra udgivelsen og afspejler ændringer i salg uden for udgivelser.
Objekter inden for leverancerne overlappede hinanden, især i den eksekverbare kode, som var mindre end halvt unik. Der var mange afhængigheder både af den allerede installerede kode og af den, hvis installation lige var planlagt.
For at få den krævede version af koden var det nødvendigt nøje at følge installationsrækkefølgen, hvor objekter blev fysisk omskrevet mange gange, omkring 10-12 gange.
Efter at have installeret et parti pakker, måtte jeg manuelt følge instruktionerne for at initialisere indstillingerne. Udgivelsen blev samlet og installeret af leverandøren. Sammensætningen af udgivelsen blev afklaret næsten før implementeringstidspunktet, hvilket indebar oprettelse af "afkoblings"-pakker. Som følge heraf flyttede en betydelig del af forsyningerne sig fra frigivelse til udgivelse med sin egen hale af "afkoblinger".
Nu er det klart, at med denne tilgang - at samle udgivelsespuslespillet på pakkeniveau - havde en enkelt mastergren ingen praktisk betydning. Installation på produktion tog fra halvanden til to timers manuelt arbejde. Det er godt, at rækkefølgen af objektbehandling i det mindste på installatørniveau blev specificeret: felter og strukturer blev indtastet før dataene for dem og procedurer. Dette fungerede dog kun i en separat pakke.
Det logiske resultat af denne tilgang var de obligatoriske installationsfejl i form af skæve versioner af objekter, unødvendig kode, manglende instruktioner og uovervejede gensidige påvirkninger af objekter, som febrilsk blev elimineret efter frigivelsen.
Første opdateringer: forpligte montering og levering
Automatisering begyndte med at sende kode gennem et rør langs denne rute:
- Afhent den færdige levering fra lageret;
- Installer det i et dedikeret miljø;
- Kør autotests;
- Evaluer installationsresultatet;
- Kald følgende pipeline på siden af testkommandoen.
Den næste pipeline skal registrere opgaven i Jira og vente på, at kommandoer distribueres til udvalgte testsløjfer, som afhænger af timingen af opgaveimplementeringen. Trigger - et brev om klarhed til levering til en given adresse. Dette var selvfølgelig en oplagt krykke, men jeg var nødt til at starte et sted. I maj 2019 begyndte overførslen af kode med kontrol af vores miljøer. Processen er begyndt, alt, der er tilbage, er at bringe det i anstændig form:
- Hver modifikation udføres i en separat gren, som svarer til installationspakken og smelter sammen i målmastergrenen;
- Pipeline-lanceringens trigger er udseendet af en ny commit i master-grenen gennem en merge-anmodning, som lukkes af vedligeholdere fra det interne team;
- Lagre synkroniseres en gang hvert femte minut;
- Monteringen af installationspakken påbegyndes - ved hjælp af den assembler, der er modtaget fra leverandøren.
Efter dette var der allerede eksisterende trin til at kontrollere og overføre koden, for at starte røret og samle på vores side.
Denne mulighed blev lanceret i juli. Vanskelighederne ved overgangen resulterede i en vis utilfredshed blandt leverandøren og frontlinjen, men i løbet af den næste måned lykkedes det at fjerne alle de hårde kanter og etablere en proces blandt teamene. Vi har nu montage ved commit og levering.
I august lykkedes det at færdiggøre den første installation af en separat pakke i produktionen ved hjælp af vores pipeline, og siden september er alle installationer af individuelle non-release-pakker blevet udført gennem vores cd-værktøj. Derudover formåede vi at opnå en andel af interne opgaver i 40% af udgivelsessammensætningen med et mindre team end leverandøren - det er en klar succes. Den mest alvorlige opgave forblev - at samle og installere udgivelsen.
Den endelige løsning: kumulative installationspakker
Vi forstod udmærket, at scripting af leverandørens instruktioner var en halvdårlig automatisering; vi var nødt til at genoverveje selve processen. Løsningen var indlysende - at indsamle en kumulativ forsyning fra udgivelsesgrenen med alle objekterne i de nødvendige versioner.
Vi startede med proof of concept: vi håndsamlede udgivelsespakken i henhold til indholdet af den tidligere implementering og installerede den på vores miljøer. Alt fungerede, konceptet viste sig at være levedygtigt. Dernæst løste vi problemet med at scripte initialiseringsindstillingerne og inkludere dem i commit. Vi forberedte en ny pakke og testede den i testmiljøer som en del af konturopdateringen. Installationen var vellykket, dog med en lang række kommentarer fra implementeringsteamet. Men det vigtigste er, at vi fik grønt lys til at gå i produktion i novemberudgivelsen med vores montage.
Med lidt over en måned tilbage antydede de håndplukkede forsyninger tydeligt, at tiden var ved at løbe ud. De besluttede at bygge fra udgivelsesgrenen, men hvorfor skulle den adskilles? Vi har ikke en Prod-lignende, og eksisterende filialer er ikke gode - der er en masse unødvendig kode. Vi har et presserende behov for at skære ned på prod-likes, og det er over tre tusinde commits. At samle i hånden er slet ikke en mulighed. Vi har skitseret et script, der løber gennem produktinstallationsloggen og indsamler tilsagn til filialen. Tredje gang virkede det korrekt, og efter at have "afsluttet med en fil" var grenen klar.
Vi skrev vores egen builder til installationspakken og færdiggjorde den på en uge. Så var vi nødt til at ændre installationsprogrammet fra systemets kernefunktionalitet, da det er open source. Efter en række kontroller og modifikationer blev resultatet betragtet som vellykket. I mellemtiden tog sammensætningen af udgivelsen form, for den korrekte installation af hvilken det var nødvendigt at justere testkredsløbet med produktionen, og et separat script blev skrevet til dette.
Naturligvis var der mange kommentarer til den første installation, men generelt fungerede koden. Og efter omkring den tredje installation begyndte alt at se godt ud. Sammensætningskontrol og versionskontrol af objekter blev overvåget separat i manuel tilstand, hvilket på dette stadium var ret berettiget.
En yderligere udfordring var det store antal ikke-udgivelser, der skulle tages i betragtning. Men med den Prod-lignende gren og Rebase blev opgaven gennemsigtig.
Første gang, hurtigt og uden fejl
Vi nærmede os udgivelsen med en optimistisk holdning og mere end et dusin vellykkede installationer på forskellige kredsløb. Men bogstaveligt talt en dag før deadline viste det sig, at sælgeren ikke havde afsluttet arbejdet med at forberede udgivelsen til installation på den accepterede måde. Hvis vores build af en eller anden grund ikke virker, vil udgivelsen blive afbrudt. Desuden gennem vores indsats, hvilket er særligt ubehageligt. Vi havde ingen mulighed for at trække os tilbage. Derfor gennemtænkte vi alternative muligheder, udarbejdede handlingsplaner og begyndte installationen.
Overraskende nok startede hele udgivelsen, bestående af mere end 800 objekter, korrekt, første gang og på kun 10 minutter. Vi brugte en time på at tjekke logfilerne på udkig efter fejl, men fandt ingen.
Hele næste dag var der tavshed i udgivelseschatten: ingen implementeringsproblemer, skæve versioner eller "upassende" kode. Det var endda på en eller anden måde akavet. Senere dukkede nogle kommentarer op, men sammenlignet med andre systemer og tidligere erfaringer var deres antal og prioritet mærkbart lavere.
En yderligere effekt fra den kumulative effekt var en stigning i kvaliteten af montering og test. På grund af flere installationer af den fulde udgivelse blev build-fejl og implementeringsfejl identificeret rettidigt. Afprøvning i fuld udgivelseskonfigurationer gjorde det muligt yderligere at identificere defekter i den gensidige påvirkning af objekter, der ikke dukkede op under trinvise installationer. Det var bestemt en succes, især i betragtning af vores bidrag på 57 % til udgivelsen.
Resumé og konklusioner
På mindre end et år lykkedes det os at:
- Byg en fuldgyldig intern udvikling ved hjælp af et eksotisk system;
- Eliminer kritisk leverandørafhængighed;
- Start CI/CD for en meget uvenlig arv;
- Hæve implementeringsprocesser til et nyt teknisk niveau;
- Reducer implementeringstiden markant;
- Reducer antallet af implementeringsfejl markant;
- Erklær dig selvsikkert som en førende udviklingsekspert.
Selvfølgelig ligner meget af det, der beskrives, direkte lort, men det er funktionerne i systemet og de procesbegrænsninger, der findes i det. I øjeblikket påvirkede ændringerne IS Profiles produkter og tjenester (masterkonti, plastikkort, opsparingskonti, escrow, kontantlån), men potentielt kan tilgangen anvendes på enhver IS, som opgaven med at implementere DevOps-praksis er sat til. Den kumulative model kan sikkert replikeres til efterfølgende implementeringer (inklusive ikke-udgivne) fra mange leverancer.
Kilde: www.habr.com