DevOps-praktyke werk. Ons was self daarvan oortuig toe ons die vrystelling-installasietyd met 10 keer verminder het. In die FIS-profielstelsel, wat ons by VTB gebruik, neem installasie nou 90 minute eerder as 10. Die vrystellingboutyd het van twee weke tot twee dae afgeneem. Die aantal aanhoudende implementeringsdefekte het tot byna 'n minimum gedaal. Om weg te kom van “handearbeid” en afhanklikheid van die verkoper uit te skakel, moes ons met krukke werk en onverwagte oplossings vind. Onder die snit is 'n gedetailleerde storie oor hoe ons 'n volwaardige interne ontwikkeling gebou het.
Voorwoord: DevOps is 'n filosofie
Ons het die afgelope jaar baie werk gedoen om die interne ontwikkeling en implementering van DevOps-praktyke by VTB te organiseer:
- Ons het interne ontwikkelingsprosesse vir 12 stelsels gebou;
- Ons het 15 pypleidings bekendgestel, waarvan vier na produksie gebring is;
- Outomatiese 1445 toets scenario's;
- Ons het 'n aantal vrystellings suksesvol geïmplementeer wat deur interne spanne voorberei is.
Een van die moeilikste om interne ontwikkeling en implementering van DevSecOps-praktyke te organiseer, blyk die FIS-profielstelsel te wees - 'n kleinhandelprodukverwerker op 'n nie-relasionele DBBS. Nietemin kon ons die ontwikkeling bou, die pyplyn bekendstel, individuele nie-vrystelling pakkette op die produk installeer, en geleer hoe om vrystellings saam te stel. Die taak was nie maklik nie, maar interessant en sonder ooglopende beperkings in implementering: hier is die stelsel - jy moet 'n interne ontwikkeling bou. Die enigste voorwaarde is om die CD voor 'n produktiewe omgewing te gebruik.
Aanvanklik het die implementeringsalgoritme eenvoudig en duidelik gelyk:
- Ons ontwikkel aanvanklike ontwikkelingskundigheid en bereik 'n aanvaarbare vlak van kwaliteit van die kodespan sonder growwe gebreke;
- Ons integreer soveel as moontlik in bestaande prosesse;
- Om kode tussen voor die hand liggende stadiums oor te dra, sny ons 'n pyplyn en druk een van sy ente in die voortsetting.
Gedurende hierdie tyd moet die ontwikkelingspan van die vereiste grootte vaardighede ontwikkel en die deel van sy bydrae tot vrystellings tot 'n aanvaarbare vlak verhoog. En dit is dit, ons kan die taak as voltooi beskou.
Dit wil voorkom asof dit 'n heeltemal energiedoeltreffende pad na die vereiste resultaat is: hier is DevOps, hier is die span se prestasie-maatstawwe, hier is die opgehoopte kundigheid ... Maar in die praktyk het ons nog 'n bevestiging gekry dat DevOps steeds oor filosofie gaan , en nie "geheg aan die gitlab-proses, ansible, nexus en verder op die lys nie."
Nadat ons die aksieplan weereens ontleed het, het ons besef dat ons besig was om 'n soort uitkontrakteringsverskaffer binne onsself te bou. Daarom is prosesherontwerp by die algoritme wat hierbo beskryf is bygevoeg, asook die ontwikkeling van kundigheid langs die hele ontwikkelingsroete om 'n leidende rol in hierdie proses te bereik. Nie die maklikste opsie nie, maar dit is die pad van ideologies korrekte ontwikkeling.
Waar begin interne ontwikkeling?
Dit was nie die mees vriendelike stelsel om mee te werk nie. Argitektonies was dit een groot nie-relasionele DBBS, wat bestaan het uit baie afsonderlike uitvoerbare voorwerpe (skrifte, prosedures, bondels, ens.), wat geroep is soos nodig, en het gewerk op die beginsel van 'n swart boks: dit ontvang 'n versoek en kwessies n reaksie. Ander probleme wat die moeite werd is om op te let, sluit in:
- Eksotiese taal (BOOMS);
- konsole-koppelvlak;
- Gebrek aan integrasie met gewilde outomatiseringsinstrumente en -raamwerke;
- Datavolume in tiene teragrepe;
- Vrag van meer as 2 miljoen operasies per uur;
- Belangrikheid - Besigheid-krities.
Terselfdertyd was daar geen bronkode-bewaarplek aan ons kant nie. Enigsins. Daar was dokumentasie, maar alle sleutelkennis en -bevoegdhede was aan die kant van 'n eksterne organisasie.
Ons het die ontwikkeling van die stelsel byna van nuuts af begin bemeester, met inagneming van sy kenmerke en lae verspreiding. Begin Oktober 2018:
- Het die dokumentasie en basiese beginsels van kodegenerering bestudeer;
- Ons het die kort kursus oor ontwikkeling bestudeer wat van die verkoper ontvang is;
- Aanvanklike ontwikkelingsvaardighede bemeester;
- Ons het 'n opleidingshandleiding vir nuwe spanlede saamgestel;
- Ons het ingestem om die span in "geveg"-modus in te sluit;
- Die probleem opgelos met kode kwaliteit beheer;
- Ons het 'n stand vir ontwikkeling georganiseer.
Ons het drie maande spandeer om kundigheid te ontwikkel en onsself in die stelsel te verdiep, en vanaf die begin van 2019 het interne ontwikkeling sy beweging na 'n blink toekoms begin, soms met moeite, maar met selfvertroue en doelgerig.
Bewaar migrasie en outotoetse
Die eerste DevOps-taak is die bewaarplek. Ons het vinnig ooreengekom om toegang te verskaf, maar dit was nodig om van die huidige SVN met een stamtak na ons teiken Git te migreer met die oorgang na 'n model van verskeie takke en ontwikkeling van Git Flow. Ons het ook 2 spanne met hul eie infrastruktuur, plus 'n deel van die verkoper se span in die buiteland. Ek moes met twee Gits saamleef en sinchronisasie verseker. In so 'n situasie was dit die minste van twee euwels.
Die migrasie van die bewaarplek is herhaaldelik uitgestel; dit is eers in April voltooi, met die hulp van kollegas van die voorste linie. Met Git Flow het ons besluit om dinge vir 'n begin eenvoudig te hou en het ons op die klassieke skema gevestig met hotfix, ontwikkel en vrystelling. Hulle het besluit om meester (ook bekend as prod-agtige) te laat vaar. Hieronder sal ons verduidelik waarom hierdie opsie vir ons optimaal geblyk het te wees. 'n Eksterne bewaarplek wat aan die verkoper behoort, wat algemeen is vir twee spanne, is as 'n werker gebruik. Dit is volgens 'n skedule gesinchroniseer met die interne bewaarplek. Nou met Git en Gitlab was dit moontlik om prosesse te outomatiseer.
Die kwessie van outotoetse is verbasend maklik opgelos - ons is voorsien van 'n klaargemaakte raamwerk. Met inagneming van die eienaardighede van die stelsel, was die oproep van 'n aparte operasie 'n verstaanbare deel van die besigheidsproses en het terselfdertyd as 'n eenheidstoets gedien. Al wat oorgebly het, was om die toetsdata voor te berei en die gewenste volgorde te stel om die skrifte te roep en die resultate te evalueer. Namate die lys scenario's, gevorm op grond van operasiestatistieke, die kritiekheid van prosesse en die bestaande regressiemetodologie, ingevul is, het outomatiese toetse begin verskyn. Nou kon ons die pyplyn begin bou.
Hoe dit was: die model voor outomatisering
Die bestaande model van die implementeringsproses is 'n aparte storie. Elke wysiging is met die hand as 'n aparte inkrementele installasiepakket oorgedra. Volgende het handregistrasie in Jira en handmatige installasie op omgewings gekom. Vir individuele pakkette het alles duidelik gelyk, maar met die voorbereiding van die vrystelling was dinge meer ingewikkeld.
Vergadering is uitgevoer op die vlak van individuele aflewerings, wat onafhanklike voorwerpe was. Enige verandering is 'n nuwe aflewering. Daar is onder meer 60–70 tegniese weergawes by die 10-15 pakkette van die hoofvrystellingsamestelling gevoeg – weergawes wat verkry is wanneer iets by die vrystelling bygevoeg of uitgesluit word en veranderinge in verkope buite vrystellings weerspieël.
Voorwerpe binne die aflewerings het met mekaar oorvleuel, veral in die uitvoerbare kode, wat minder as die helfte uniek was. Daar was baie afhanklikhede van beide die reeds geïnstalleerde kode en op die een wie se installasie pas beplan is.
Om die vereiste weergawe van die kode te verkry, was dit nodig om die installasievolgorde streng te volg, waartydens voorwerpe baie keer fisies herskryf is, sowat 10–12 keer.
Nadat ek 'n bondel pakkette geïnstalleer het, moes ek instruksies handmatig volg om die instellings te inisialiseer. Die vrystelling is deur die verkoper saamgestel en geïnstalleer. Die samestelling van die vrystelling is amper voor die oomblik van implementering uitgeklaar, wat die skepping van "ontkoppeling"-pakkette behels het. Gevolglik het 'n beduidende deel van die voorrade van vrystelling na vrystelling beweeg met sy eie stert van "ontkoppelings".
Nou is dit duidelik dat met hierdie benadering - die samestelling van die vrystelling legkaart op pakketvlak - 'n enkele meestertak geen praktiese betekenis gehad het nie. Installasie op produksie het van een en 'n half tot twee uur se handearbeid geneem. Dit is goed dat die volgorde van objekverwerking ten minste op die installeerdervlak gespesifiseer is: velde en strukture is ingevoer voor die data daarvoor en prosedures. Dit het egter net binne 'n aparte pakket gewerk.
Die logiese gevolg van hierdie benadering was die verpligte installasie-defekte in die vorm van skewe weergawes van voorwerpe, onnodige kode, ontbrekende instruksies en onverklaarbare wedersydse invloede van voorwerpe, wat koorsagtig uitgeskakel is na vrylating.
Eerste opdaterings: pleeg montering en aflewering
Outomatisering het begin deur kode deur 'n pyp langs hierdie roete te stuur:
- Haal die voltooide aflewering by stoor af;
- Installeer dit op 'n toegewyde omgewing;
- Voer outotoetse uit;
- Evalueer die installasie resultaat;
- Bel die volgende pyplyn aan die kant van die toetsopdrag.
Die volgende pyplyn moet die taak in Jira registreer en wag dat opdragte na geselekteerde toetslusse versprei word, wat afhang van die tydsberekening van die taakimplementering. Sneller - 'n brief oor gereedheid vir aflewering by 'n gegewe adres. Dit was natuurlik 'n ooglopende kruk, maar ek moes iewers begin. In Mei 2019 het die oordrag van kode begin met kontrole van ons omgewings. Die proses het begin, al wat oorbly is om dit in ordentlike vorm te bring:
- Elke wysiging word in 'n aparte tak uitgevoer, wat ooreenstem met die installasiepakket en saamsmelt in die teikenmeestertak;
- Die pyplyn bekendstelling sneller is die verskyning van 'n nuwe commit in die meester tak deur 'n samesmelting versoek, wat gesluit word deur instandhouers van die interne span;
- Bewaarplekke word een keer elke vyf minute gesinchroniseer;
- Die samestelling van die installasiepakket word begin - met behulp van die samesteller wat van die verkoper ontvang is.
Hierna was daar reeds bestaande stappe om die kode na te gaan en oor te dra, om die pyp te lanseer en aan ons kant te monteer.
Hierdie opsie is in Julie bekendgestel. Die probleme van die oorgang het gelei tot 'n mate van ontevredenheid onder die verkoper en die voorste linie, maar oor die volgende maand het ons daarin geslaag om al die ruwe kante te verwyder en 'n proses onder die spanne te vestig. Ons het nou samestelling deur toewyding en aflewering.
In Augustus het ons daarin geslaag om die eerste installasie van 'n aparte pakket op produksie met behulp van ons pyplyn te voltooi, en sedert September, sonder uitsondering, is alle installasies van individuele nie-vrystelling pakkette deur ons CD-instrument uitgevoer. Daarbenewens het ons daarin geslaag om 'n deel van interne take in 40% van die vrystellingsamestelling te bereik met 'n kleiner span as die verkoper - dit is 'n besliste sukses. Die ernstigste taak het gebly - om die vrystelling te monteer en te installeer.
Die finale oplossing: kumulatiewe installasiepakkette
Ons het baie goed verstaan dat die skryf van die verkoper se instruksies 'n so-so outomatisering was; ons moes die proses self heroorweeg. Die oplossing was voor die hand liggend - om 'n kumulatiewe voorraad van die vrystellingtak te versamel met al die voorwerpe van die vereiste weergawes.
Ons het begin met bewys van konsep: ons het die vrystellingpakket met die hand saamgestel volgens die inhoud van die vorige implementering en dit op ons omgewings geïnstalleer. Alles het uitgewerk, die konsep het geblyk lewensvatbaar te wees. Vervolgens het ons die probleem opgelos om die inisialiseringsinstellings te skryf en dit by die commit in te sluit. Ons het 'n nuwe pakket voorberei en dit in toetsomgewings getoets as deel van die kontoeropdatering. Die installasie was suksesvol, alhoewel met 'n wye reeks opmerkings van die implementeringspan. Maar die belangrikste ding is dat ons die trekpas gekry het om in die November-vrystelling met ons samestelling in produksie te gaan.
Met net meer as 'n maand oor, het die met die hand uitgesoekte voorrade duidelik aangedui dat die tyd besig was om uit te loop. Hulle het besluit om die bou van die vrylatingtak te maak, maar hoekom moet dit geskei word? Ons het nie 'n Prod-agtige nie, en bestaande takke is nie goed nie - daar is baie onnodige kode. Ons moet dringend prod-likes sny, en dit is meer as drieduisend commits. Om met die hand bymekaar te maak is glad nie 'n opsie nie. Ons het 'n skrif geskets wat deur die produkinstallasielogboek loop en commits aan die tak versamel. Die derde keer het dit reg gewerk, en na "afgewerk met 'n lêer" was die tak gereed.
Ons het ons eie bouer vir die installasiepakket geskryf en dit binne 'n week voltooi. Toe moes ons die installeerder van die kernfunksies van die stelsel verander, aangesien dit oopbron is. Na 'n reeks kontroles en wysigings is die resultaat as suksesvol beskou. Intussen het die samestelling van die vrystelling vorm aangeneem, vir die korrekte installering waarvan dit nodig was om die toetskring met die produksie een in lyn te bring, en 'n aparte draaiboek is hiervoor geskryf.
Natuurlik was daar baie opmerkings oor die eerste installasie, maar oor die algemeen het die kode gewerk. En ná omtrent die derde installasie het alles goed begin lyk. Samestellingbeheer en weergawebeheer van voorwerpe is afsonderlik in handmodus gemonitor, wat op hierdie stadium redelik geregverdig was.
’n Bykomende uitdaging was die groot aantal nie-vrystellings wat in ag geneem moes word. Maar met die Prod-agtige tak en Rebase het die taak deursigtig geword.
Eerste keer, vinnig en sonder foute
Ons het die vrystelling benader met 'n optimistiese houding en meer as 'n dosyn suksesvolle installasies op verskillende stroombane. Maar letterlik 'n dag voor die sperdatum het dit geblyk dat die verkoper nie die werk voltooi het om die vrystelling vir installasie op die aanvaarde manier voor te berei nie. As ons bou om een of ander rede nie werk nie, sal die vrystelling ontwrig word. Verder, deur ons pogings, wat veral onaangenaam is. Ons het geen manier gehad om terug te trek nie. Daarom het ons alternatiewe opsies deurgedink, aksieplanne opgestel en begin met installasie.
Verbasend genoeg het die hele vrystelling, wat uit meer as 800 voorwerpe bestaan, reg begin, die eerste keer en in net 10 minute. Ons het 'n uur spandeer om die logs na te gaan op soek na foute, maar het niks gevind nie.
Die hele volgende dag was daar stilte in die vrystellingklets: geen implementeringsprobleme, skewe weergawes of "onvanpaste" kode nie. Dit was selfs op een of ander manier ongemaklik. Later het sommige opmerkings na vore gekom, maar in vergelyking met ander stelsels en vorige ondervinding was hul getal en prioriteit merkbaar laer.
'n Bykomende effek van die kumulatiewe effek was 'n toename in die kwaliteit van samestelling en toetsing. As gevolg van veelvuldige installasies van die volledige vrystelling, is boufoute en ontplooiingsfoute betyds geïdentifiseer. Toetsing in volle vrystelling-konfigurasies het dit moontlik gemaak om bykomend defekte in die wedersydse invloed van voorwerpe te identifiseer wat nie tydens inkrementele installasies verskyn het nie. Dit was beslis 'n sukses, veral gegewe ons 57% bydrae tot die vrystelling.
Samevatting en gevolgtrekkings
In minder as 'n jaar het ons daarin geslaag om:
- Bou 'n volwaardige interne ontwikkeling deur 'n eksotiese stelsel te gebruik;
- Elimineer kritieke verkoperafhanklikheid;
- Begin CI/CD vir 'n baie onvriendelike nalatenskap;
- Verhoog implementeringsprosesse na 'n nuwe tegniese vlak;
- Verminder ontplooiingstyd aansienlik;
- Verminder die aantal implementeringsfoute aansienlik;
- Verklaar jouself met selfvertroue as 'n toonaangewende ontwikkelingskenner.
Natuurlik lyk baie van wat beskryf word na volslae kak, maar dit is die kenmerke van die stelsel en die prosesbeperkings wat daarin bestaan. Op die oomblik het die veranderinge IS-profiel-produkte en -dienste (meesterrekeninge, plastiekkaarte, spaarrekeninge, borg, kontantlenings) geraak, maar moontlik kan die benadering toegepas word op enige IS waarvoor die taak gestel is om DevOps-praktyke te implementeer. Die kumulatiewe model kan veilig gerepliseer word vir daaropvolgende implementerings (insluitend nie-vrystellings) vanaf baie aflewerings.
Bron: will.com