DevOps-praksis fungerer. Vi var selv overbevist om dette da vi reduserte installasjonstiden for utgivelsen med 10 ganger. I FIS Profile-systemet, som vi bruker på VTB, tar installasjonen nå 90 minutter i stedet for 10. Utgivelsesbyggetiden har gått ned fra to uker til to dager. Antallet vedvarende implementeringsfeil har sunket til nesten et minimum. For å komme vekk fra "manuelt arbeid" og eliminere avhengighet av leverandøren, måtte vi jobbe med krykker og finne uventede løsninger. Under kuttet er en detaljert historie om hvordan vi bygde en fullverdig intern utvikling.
Prolog: DevOps er en filosofi
I løpet av det siste året har vi gjort mye arbeid for å organisere intern utvikling og implementering av DevOps-praksis ved VTB:
- Vi bygget interne utviklingsprosesser for 12 systemer;
- Vi lanserte 15 rørledninger, hvorav fire ble satt i produksjon;
- Automatiserte 1445 testscenarier;
- Vi har implementert en rekke utgivelser utarbeidet av interne team.
En av de vanskeligste å organisere intern utvikling og implementering av DevSecOps-praksis viste seg å være FIS Profile-systemet - en detaljhandelsproduktprosessor på et ikke-relasjonelt DBMS. Ikke desto mindre var vi i stand til å bygge utviklingen, lansere pipeline, installere individuelle ikke-utgivelsespakker på produktet og lært å sette sammen utgivelser. Oppgaven var ikke lett, men interessant og uten åpenbare begrensninger i implementeringen: her er systemet - du må bygge en egenutvikling. Den eneste betingelsen er å bruke CD-en før et produktivt miljø.
Til å begynne med virket implementeringsalgoritmen enkel og klar:
- Vi utvikler innledende utviklingskompetanse og oppnår et akseptabelt kvalitetsnivå fra kodeteamet uten grove feil;
- Vi integrerer i eksisterende prosesser så mye som mulig;
- For å overføre kode mellom åpenbare stadier, kutter vi en rørledning og skyver en av endene inn i fortsettelsen.
I løpet av denne tiden må utviklingsteamet av nødvendig størrelse utvikle ferdigheter og øke andelen av sitt bidrag til utgivelser til et akseptabelt nivå. Og det er det, vi kan vurdere oppgaven som fullført.
Det ser ut til at dette er en fullstendig energieffektiv vei til ønsket resultat: her er DevOps, her er teamets ytelsesmålinger, her er den akkumulerte ekspertisen... Men i praksis fikk vi nok en bekreftelse på at DevOps fortsatt handler om filosofi , og ikke "knyttet til gitlab-prosessen, ansible, nexus og lenger ned på listen."
Etter å ha analysert handlingsplanen nok en gang, innså vi at vi bygde en slags outsourceleverandør i oss selv. Derfor ble prosessreengineering lagt til algoritmen beskrevet ovenfor, samt utvikling av kompetanse langs hele utviklingsveien for å oppnå en ledende rolle i denne prosessen. Ikke det enkleste alternativet, men dette er veien til ideologisk riktig utvikling.
Hvor begynner egenutviklingen?
Det var ikke det mest vennlige systemet å jobbe med. Arkitektonisk var det en stor ikke-relasjonell DBMS, besto av mange separate kjørbare objekter (skript, prosedyrer, batcher, etc.), som ble kalt etter behov, og jobbet etter prinsippet om en svart boks: den mottar en forespørsel og utsteder et svar. Andre vanskeligheter som er verdt å merke seg inkluderer:
- Eksotisk språk (MUMPS);
- konsoll grensesnitt;
- Mangel på integrasjon med populære automatiseringsverktøy og rammeverk;
- Datavolum i titalls terabyte;
- Belastning på over 2 millioner operasjoner per time;
- Betydning - Forretningskritisk.
Samtidig var det ikke noe kildekodelager på vår side. I det hele tatt. Det var dokumentasjon, men all nøkkelkunnskap og kompetanse var på siden av en ekstern organisasjon.
Vi begynte å mestre utviklingen av systemet nesten fra bunnen av, med tanke på funksjoner og lav distribusjon. Startet i oktober 2018:
- Studerte dokumentasjonen og grunnleggende om kodegenerering;
- Vi studerte det korte kurset om utvikling mottatt fra leverandøren;
- Mestret innledende utviklingsferdigheter;
- Vi har laget en opplæringsmanual for nye teammedlemmer;
- Vi ble enige om å inkludere laget i "kamp"-modus;
- Løste problemet med kodekvalitetskontroll;
- Vi arrangerte en stand for utvikling.
Vi brukte tre måneder på å utvikle kompetanse og fordype oss i systemet, og fra begynnelsen av 2019 begynte intern utvikling sin bevegelse mot en lys fremtid, noen ganger med vanskeligheter, men selvsikkert og målrettet.
Lagringsmigrering og autotester
Den første DevOps-oppgaven er depotet. Vi ble raskt enige om å gi tilgang, men det var nødvendig å migrere fra det nåværende SVN med én trunkgren til vårt mål Git med overgangen til en modell av flere grener og utvikling av Git Flow. Vi har også 2 team med egen infrastruktur, pluss en del av leverandørens team i utlandet. Jeg måtte leve med to Gits og sørge for synkronisering. I en slik situasjon var det det minste av to onder.
Migreringen av depotet ble gjentatte ganger utsatt; den ble fullført først i april, med hjelp fra kolleger fra frontlinjen. Med Git Flow bestemte vi oss for å holde ting enkelt til å begynne med og slo oss til ro med det klassiske opplegget med hurtigreparasjoner, utvikling og utgivelse. De bestemte seg for å forlate master (aka prod-lignende). Nedenfor vil vi forklare hvorfor dette alternativet viste seg å være optimalt for oss. Et eksternt depot tilhørende leverandøren, felles for to team, ble brukt som arbeider. Det synkroniserte med det interne depotet i henhold til en tidsplan. Nå med Git og Gitlab var det mulig å automatisere prosesser.
Spørsmålet om autotester ble løst overraskende enkelt - vi ble utstyrt med et ferdig rammeverk. Med tanke på systemets særegenheter, var det å kalle en separat operasjon en forståelig del av forretningsprosessen og fungerte samtidig som en enhetstest. Alt som gjensto var å forberede testdataene og sette ønsket rekkefølge for å ringe skriptene og evaluere resultatene. Etter hvert som listen over scenarier, dannet på grunnlag av operasjonsstatistikk, kritikaliteten til prosesser og eksisterende regresjonsmetodikk, ble fylt ut, begynte automatiske tester å dukke opp. Nå kunne vi begynne å bygge rørledningen.
Slik var det: modellen før automatisering
Den eksisterende modellen for implementeringsprosessen er en egen historie. Hver modifikasjon ble manuelt overført som en separat inkrementell installasjonspakke. Deretter kom manuell registrering i Jira og manuell installasjon på miljøer. For individuelle pakker så alt klart ut, men med utarbeidelsen av utgivelsen var ting mer komplisert.
Montering ble utført på nivå med individuelle leveranser, som var selvstendige objekter. Enhver endring er en ny leveranse. Blant annet ble 60–70 tekniske versjoner lagt til de 10–15 pakkene av hovedutgivelsessammensetningen – versjoner oppnådd ved å legge til eller ekskludere noe fra utgivelsen og reflektere endringer i salg utenfor utgivelser.
Objekter i leveransene overlappet med hverandre, spesielt i den kjørbare koden, som var mindre enn halvparten unik. Det var mange avhengigheter både av den allerede installerte koden og den som nettopp var planlagt installert.
For å få den nødvendige versjonen av koden, var det nødvendig å strengt følge installasjonsrekkefølgen, hvor objekter ble fysisk omskrevet mange ganger, rundt 10–12 ganger.
Etter å ha installert et parti med pakker, måtte jeg manuelt følge instruksjonene for å initialisere innstillingene. Utgivelsen ble satt sammen og installert av leverandøren. Sammensetningen av utgivelsen ble avklart nesten før implementeringsøyeblikket, noe som innebar opprettelsen av "frakoblings"-pakker. Som et resultat flyttet en betydelig del av forsyningene fra utgivelse til utgivelse med sin egen hale av "frakoblinger".
Nå er det klart at med denne tilnærmingen - å sette sammen utgivelsespuslespillet på pakkenivå - hadde en enkelt mastergren ingen praktisk betydning. Installasjon på produksjon tok fra halvannen til to timers manuelt arbeid. Det er bra at i det minste på installatørnivå ble rekkefølgen for objektbehandling spesifisert: felt og strukturer ble lagt inn før dataene for dem og prosedyrer. Dette fungerte imidlertid kun innenfor en egen pakke.
Det logiske resultatet av denne tilnærmingen var de obligatoriske installasjonsfeilene i form av skjeve versjoner av objekter, unødvendig kode, manglende instruksjoner og uklare gjensidige påvirkninger av objekter, som febrilsk ble eliminert etter utgivelsen.
Første oppdateringer: forplikte montering og levering
Automatisering begynte med å overføre kode gjennom et rør langs denne ruten:
- Hent den ferdige leveransen fra lageret;
- Installer den i et dedikert miljø;
- Kjør autotester;
- Evaluer installasjonsresultatet;
- Ring følgende pipeline på siden av testkommandoen.
Den neste rørledningen skal registrere oppgaven i Jira og vente på at kommandoer skal distribueres til utvalgte testløkker, som avhenger av tidspunktet for oppgaveimplementeringen. Trigger - et brev om leveringsberedskap til en gitt adresse. Dette var selvfølgelig en åpenbar krykke, men jeg måtte begynne et sted. I mai 2019 startet overføringen av kode med kontroller av våre miljøer. Prosessen har begynt, alt som gjenstår er å bringe den i anstendig form:
- Hver modifikasjon utføres i en separat gren, som tilsvarer installasjonspakken og smelter sammen med målhovedgrenen;
- Utløseren for pipelinelansering er utseendet til en ny forpliktelse i hovedgrenen gjennom en sammenslåingsforespørsel, som lukkes av vedlikeholdere fra internteamet;
- Lagre synkroniseres en gang hvert femte minutt;
- Monteringen av installasjonspakken startes - ved hjelp av montøren mottatt fra leverandøren.
Etter dette var det allerede eksisterende trinn for å sjekke og overføre koden, for å starte røret og montere på vår side.
Dette alternativet ble lansert i juli. Vanskelighetene med overgangen resulterte i noe misnøye blant leverandøren og frontlinjen, men i løpet av den neste måneden klarte vi å fjerne alle de grove kantene og etablere en prosess blant teamene. Vi har nå montering ved forpliktelse og levering.
I august klarte vi å fullføre den første installasjonen av en egen pakke på produksjon ved hjelp av vår pipeline, og siden september, uten unntak, er alle installasjoner av individuelle ikke-utgivelsespakker utført gjennom vårt CD-verktøy. I tillegg klarte vi å oppnå en andel av interne oppgaver i 40 % av utgivelsessammensetningen med et mindre team enn leverandøren – dette er en klar suksess. Den mest alvorlige oppgaven gjensto - å montere og installere utgivelsen.
Den endelige løsningen: kumulative installasjonspakker
Vi forsto utmerket godt at skripting av leverandørens instruksjoner var en så som så automatisering; vi måtte revurdere selve prosessen. Løsningen var åpenbar - å samle en kumulativ forsyning fra utgivelsesgrenen med alle objektene til de nødvendige versjonene.
Vi startet med proof of concept: vi håndmonterte utgivelsespakken i henhold til innholdet i forrige implementering og installerte den på våre miljøer. Alt ordnet seg, konseptet viste seg å være levedyktig. Deretter løste vi problemet med å skripte initialiseringsinnstillingene og inkludere dem i commit. Vi utarbeidet en ny pakke og testet den i testmiljøer som en del av konturoppdateringen. Installasjonen var vellykket, om enn med et bredt spekter av kommentarer fra implementeringsteamet. Men hovedsaken er at vi fikk klarsignal til å gå i produksjon i novemberutgivelsen med monteringen vår.
Med litt over en måned igjen antydet de håndplukkede forsyningene tydelig at tiden var i ferd med å renne ut. De bestemte seg for å bygge fra utgivelsesgrenen, men hvorfor skulle den skilles? Vi har ikke en Prod-lignende, og eksisterende grener er ikke bra - det er mye unødvendig kode. Vi trenger snarest å kutte prod-likes, og dette er over tre tusen forpliktelser. Montering for hånd er ikke et alternativ i det hele tatt. Vi skisserte et skript som går gjennom produktinstallasjonsloggen og samler inn forpliktelser til avdelingen. Tredje gangen fungerte det riktig, og etter "avsluttet med fil" var grenen klar.
Vi skrev vår egen byggherre for installasjonspakken og ble ferdig med den på en uke. Deretter måtte vi endre installasjonsprogrammet fra kjernefunksjonaliteten til systemet, siden det er åpen kildekode. Etter en rekke kontroller og modifikasjoner ble resultatet ansett som vellykket. I mellomtiden tok sammensetningen av utgivelsen form, for den riktige installasjonen var det nødvendig å justere testkretsen med produksjonen, og et eget manus ble skrevet for dette.
Naturligvis var det mange kommentarer om den første installasjonen, men totalt sett fungerte koden. Og etter omtrent den tredje installasjonen begynte alt å se bra ut. Komposisjonskontroll og versjonskontroll av objekter ble overvåket separat i manuell modus, noe som på dette stadiet var ganske berettiget.
En ekstra utfordring var det store antallet ikke-utgivelser som måtte tas i betraktning. Men med den Prod-lignende grenen og Rebase ble oppgaven gjennomsiktig.
Første gang, raskt og uten feil
Vi nærmet oss utgivelsen med en optimistisk holdning og mer enn et dusin vellykkede installasjoner på forskjellige kretser. Men bokstavelig talt et døgn før deadline viste det seg at leverandøren ikke hadde fullført arbeidet med å forberede utgivelsen for installasjon på akseptert måte. Hvis bygget av en eller annen grunn ikke fungerer, vil utgivelsen bli forstyrret. Dessuten, gjennom vår innsats, noe som er spesielt ubehagelig. Vi hadde ingen mulighet til å trekke oss tilbake. Derfor tenkte vi gjennom alternative muligheter, utarbeidet handlingsplaner og startet installasjonen.
Overraskende nok startet hele utgivelsen, bestående av mer enn 800 objekter, riktig, første gang og på bare 10 minutter. Vi brukte en time på å sjekke loggene på jakt etter feil, men fant ingen.
Hele neste dag var det stille i utgivelseschatten: ingen implementeringsproblemer, skjeve versjoner eller "upassende" kode. Det var til og med på en eller annen måte vanskelig. Senere dukket det opp noen kommentarer, men sammenlignet med andre systemer og tidligere erfaringer var antallet og prioriteringen deres merkbart lavere.
En tilleggseffekt fra den kumulative effekten var en økning i kvaliteten på montering og testing. På grunn av flere installasjoner av den fullstendige utgivelsen, ble byggefeil og distribusjonsfeil identifisert i tide. Testing i konfigurasjoner med full utgivelse gjorde det mulig i tillegg å identifisere defekter i gjensidig påvirkning av objekter som ikke dukket opp under inkrementelle installasjoner. Det var definitivt en suksess, spesielt gitt vårt bidrag på 57 % til utgivelsen.
Resultater og konklusjoner
På mindre enn ett år klarte vi å:
- Bygg en fullverdig intern utvikling ved å bruke et eksotisk system;
- Eliminer kritisk leverandøravhengighet;
- Start CI/CD for en svært uvennlig arv;
- Heve implementeringsprosesser til et nytt teknisk nivå;
- Reduser utplasseringstiden betydelig;
- Reduser antallet implementeringsfeil betydelig;
- Erklær deg selv som en ledende utviklingsekspert.
Selvfølgelig ser mye av det som beskrives ut som direkte dritt, men dette er funksjonene til systemet og prosessbegrensningene som finnes i det. For øyeblikket påvirket endringene IS Profile-produkter og -tjenester (masterkontoer, plastkort, sparekontoer, escrow, kontantlån), men potensielt kan tilnærmingen brukes på alle IS som oppgaven med å implementere DevOps-praksis er satt for. Den kumulative modellen kan trygt replikeres for påfølgende implementeringer (inkludert ikke-utgitte) fra mange leveranser.
Kilde: www.habr.com