DevOps-praktiken wurkje. Wy wiene der sels fan oertsjûge doe't wy de ynstallaasjetiid fan 'e release mei 10 kear fermindere. Yn it FIS Profile-systeem, dat wy brûke by VTB, nimt ynstallaasje no 90 minuten yn stee fan 10. De release-boutiid is ôfnommen fan twa wiken nei twa dagen. It tal oanhâldende ymplemintaasjefouten is sakke ta hast in minimum. Om fuort te kommen fan "manuele arbeid" en elimineren ôfhinklikens fan de ferkeaper, wy moasten wurkje mei krukken en fine ûnferwachte oplossings. Under de besuniging is in detaillearre ferhaal oer hoe't wy in folsleine ynterne ûntwikkeling bouden.
Prolooch: DevOps is in filosofy
It ôfrûne jier hawwe wy in protte wurk dien om de ynterne ûntwikkeling en ymplemintaasje fan DevOps-praktiken by VTB te organisearjen:
- Wy bouden ynterne ûntwikkeling prosessen foar 12 systemen;
- Wy lansearre 15 pipelines, wêrfan fjouwer waarden brocht oan produksje;
- Automatisearre 1445 test senario;
- Wy hawwe in oantal releases mei súkses ymplementearre, taret troch eigen teams.
Ien fan 'e dreechste te organisearjen eigen ûntwikkeling en ymplemintaasje fan DevSecOps-praktiken die bliken it FIS-profylsysteem te wêzen - in retailproduktprosessor op in net-relasjonele DBMS. Dochs koene wy de ûntwikkeling bouwe, de pipeline lansearje, yndividuele net-release-pakketten op it produkt ynstallearje, en learden hoe't jo releases kinne gearstalle. De taak wie net maklik, mar ynteressant en sûnder dúdlike beheiningen yn ymplemintaasje: hjir is it systeem - jo moatte in eigen ûntwikkeling bouwe. De ienige betingst is om de CD te brûken foar in produktive omjouwing.
Yn it earstoan like it ymplemintaasjealgoritme ienfâldich en dúdlik:
- Wy ûntwikkelje initial ûntwikkeling saakkundigens en berikke in akseptabel nivo fan kwaliteit út de koade team sûnder bruto defekten;
- Wy yntegrearje safolle mooglik yn besteande prosessen;
- Om koade oer te bringen tusken dúdlike stadia, snijje wy in pipeline en triuwe ien fan syn einen yn 'e fuortsetting.
Yn dizze tiid moat it ûntwikkelteam fan 'e fereaske grutte feardigens ûntwikkelje en it oandiel fan har bydrage oan releases ferheegje nei in akseptabel nivo. En dat is it, wy kinne beskôgje de taak foltôge.
It liket derop dat dit in folslein enerzjysunich paad is nei it fereaske resultaat: hjir is DevOps, hjir binne de prestaasjesmetriken fan it team, hjir is de opboude ekspertize ... Mar yn 'e praktyk krigen wy noch in befêstiging dat DevOps noch altyd oer filosofy giet , en net "taheakke oan it gitlab-proses, ansible, nexus en fierder yn 'e list."
Nei't wy it aksjeplan nochris analysearre hawwe, realisearren wy dat wy in soarte fan outsourceferkeaper yn ússels bouwe. Dêrom waard proses-re-engineering tafoege oan it hjirboppe beskreaune algoritme, lykas ek de ûntwikkeling fan saakkundigens lâns de heule ûntwikkelingsrûte om in liedende rol yn dit proses te berikken. Net de maklikste opsje, mar dit is it paad fan ideologysk korrekte ûntwikkeling.
Wêr begjint inhouse ûntwikkeling?
It wie net it meast freonlike systeem om mei te wurkjen. Arsjitektoanysk wie it ien grutte net-relasjonele DBMS, bestie út in protte aparte útfierbere objekten (skripts, prosedueres, batches, ensfh.), dy't waarden neamd as nedich, en wurke op it prinsipe fan in swarte doaze: it ûntfangt in fersyk en problemen in antwurd. Oare swierrichheden dy't it wurdich op te merken binne:
- eksoatyske taal (MUMPS);
- konsole ynterface;
- Gebrek oan yntegraasje mei populêre automatisearringsynstruminten en kaders;
- Gegevensvolume yn tsientallen terabytes;
- Laad fan mear as 2 miljoen operaasjes per oere;
- Belang - Business-Critical.
Tagelyk wie d'r gjin boarnekoade repository oan ús kant. Heulendal. Der wie dokumintaasje, mar alle wichtige kennis en kompetinsjes wiene oan 'e kant fan in eksterne organisaasje.
Wy begon de ûntwikkeling fan it systeem hast fanôf it begjin te behearskjen, rekken hâldend mei syn funksjes en lege ferdieling. Begûn yn oktober 2018:
- Studearre de dokumintaasje en basis fan koade generaasje;
- Wy studearre de koarte kursus op ûntwikkeling ûntfongen fan de ferkeaper;
- Behearskje earste ûntwikkelingsfeardigens;
- Wy hawwe in training hânboek gearstald foar nije teamleden;
- Wy hawwe ôfpraat om it team op te nimmen yn "combat" modus;
- Oplosse it probleem mei koade kwaliteit kontrôle;
- Wy organisearre in stand foar ûntwikkeling.
Wy hawwe trije moannen bestege oan it ûntwikkeljen fan ekspertize en ûnderdompelje ússels yn it systeem, en fan it begjin fan 2019, inhouse ûntwikkeling begûn syn beweging nei in heldere takomst, soms mei muoite, mar mei fertrouwen en doelbewust.
Repository migraasje en autotests
De earste DevOps-taak is it repository. Wy binne gau iens oer it jaan fan tagong, mar it wie nedich om te migrearjen fan 'e hjoeddeistige SVN mei ien trunk-tûke nei ús doel Git mei de oergong nei in model fan ferskate tûken en ûntwikkeling fan Git Flow. Wy hawwe ek 2 teams mei harren eigen ynfrastruktuer, plus in part fan de ferkeaper syn team yn it bûtenlân. Ik moast libje mei twa Gits en soargje syngronisaasje. Yn sa'n situaasje wie it de minste fan twa kwea.
De migraasje fan it repository waard ferskate kearen útsteld; it waard pas yn april foltôge, mei help fan kollega's út 'e frontline. Mei Git Flow, wy besletten om te hâlden dingen simpel foar in begjin en fêstige op it klassike skema mei hotfix, ûntwikkeljen en frijlitte. Se besleaten master (aka prod-like) te ferlitten. Hjirûnder sille wy útlizze wêrom't dizze opsje foar ús optimaal blykte te wêzen. In eksterne repository fan de ferkeaper, mienskiplik foar twa teams, waard brûkt as arbeider. It syngronisearre mei it ynterne repository neffens in skema. No mei Git en Gitlab wie it mooglik om prosessen te automatisearjen.
It probleem fan autotests waard ferrassend maklik oplost - wy waarden foarsjoen fan in ready-made ramt. Mei it rekkenjen fan de eigenaardichheden fan it systeem, it neamen fan in aparte operaasje wie in begryplik diel fan it saaklike proses en tsjinne tagelyk as in ienheidstest. Alles wat oerbleau wie om de testgegevens te tarieden en de winske folchoarder yn te stellen fan it oproppen fan de skripts en it evaluearjen fan de resultaten. As de list fan senario's, foarme op basis fan operaasjestatistiken, de kritykens fan prosessen en de besteande regressionmetodology, ynfolje, begon automatyske tests te ferskinen. No kinne wy begjinne mei it bouwen fan de pipeline.
Hoe wie it: it model foar automatisearring
It besteande model fan it útfieringsproses is in apart ferhaal. Elke modifikaasje waard mei de hân oerdroegen as in apart inkrementeel ynstallaasjepakket. Folgjende kaam hânmjittich registraasje yn Jira en hânmjittich ynstallaasje op omjouwings. Foar yndividuele pakketten like alles dúdlik, mar mei de tarieding fan 'e release wiene dingen yngewikkelder.
Gearstalling waard útfierd op it nivo fan yndividuele leveringen, dy't ûnôfhinklike objekten wiene. Elke feroaring is in nije levering. Under oare dingen waarden 60-70 technyske ferzjes tafoege oan 'e 10-15-pakketten fan' e haadrelease-komposysje - ferzjes krigen by it tafoegjen of útsluten fan wat fan 'e release en wjerspegelje feroaringen yn ferkeap bûten releases.
Objekten binnen de leveringen oerlappe elkoar, benammen yn 'e útfierbere koade, dy't minder as de helte unyk wie. D'r wiene in protte ôfhinklikens sawol op 'e al ynstalleare koade as op' e ien waans ynstallaasje krekt pland wie.
Om de fereaske ferzje fan 'e koade te krijen, wie it nedich om de ynstallaasjefolchoarder strikt te folgjen, wêrby't objekten in protte kearen fysyk werskreaun waarden, sa'n 10-12 kear.
Nei it ynstallearjen fan in pakket pakketten, moast ik de ynstruksjes manuell folgje om de ynstellings te inisjalisearjen. De release waard gearstald en ynstalleare troch de ferkeaper. De gearstalling fan 'e frijlitting waard dúdlik makke hast foar it momint fan ymplemintaasje, dy't de oprjochting fan "ûnkoppeljen" pakketten omfette. As gefolch, in signifikant diel fan 'e foarrieden ferhuze fan frijlitting nei frijlitting mei in eigen sturt fan "ûntkoppelen".
No is it dúdlik dat mei dizze oanpak - it gearstallen fan de release-puzel op it pakketnivo - ien mastertûke gjin praktyske betsjutting hie. Ynstallaasje op produksje duorre fan ien en in heal oant twa oeren fan hânwurk. It is goed dat op syn minst op it ynstalleardernivo de folchoarder fan objektferwurking oanjûn is: fjilden en struktueren waarden ynfierd foar de gegevens foar har en prosedueres. Dit wurke lykwols allinich binnen in apart pakket.
It logyske resultaat fan dizze oanpak wie de ferplichte ynstallaasje mankeminten yn 'e foarm fan krom ferzjes fan objekten, ûnnedige koade, ûntbrekkende ynstruksjes en unaccounted ûnderlinge ynfloeden fan objekten, dy't koartsich eliminearre nei frijlitting.
Earste updates: commit montage en levering
Automatisearring begon mei it ferstjoeren fan koade fia in piip lâns dizze rûte:
- Pick up de klear levering út opslach;
- Ynstallearje it op in tawijd omjouwing;
- Autotests útfiere;
- Evaluearje it ynstallaasjeresultaat;
- Rop de folgjende pipeline oan 'e kant fan it testkommando.
De folgjende pipeline moat de taak registrearje yn Jira en wachtsje op kommando's dy't wurde ferspraat oan selekteare testloops, dy't ôfhinklik binne fan 'e timing fan' e taakimplementaasje. Trigger - in brief oer reewilligens foar levering oan in opjûn adres. Dit wie fansels in dúdlike kruk, mar ik moast earne begjinne. Yn maaie 2019 begon de oerdracht fan koade mei kontrôles op ús omjouwings. It proses is begûn, alles wat bliuwt is it yn fatsoenlike foarm te bringen:
- Elke modifikaasje wurdt útfierd yn in aparte branch, dy't oerienkomt mei it ynstallaasjepakket en fusearret yn 'e doelmastertûke;
- De trigger foar lansearring fan pipeline is it ferskinen fan in nije commit yn 'e mastertûke troch in fúzjefersyk, dat wurdt sletten troch ûnderhâlders fan it eigen team;
- Repositories wurde ien kear alle fiif minuten syngronisearre;
- De gearstalling fan it ynstallaasjepakket wurdt begon - mei de assembler ûntfongen fan 'e ferkeaper.
Dêrnei wiene d'r al besteande stappen om de koade te kontrolearjen en oer te bringen, de piip te lansearjen en oan ús kant te sammeljen.
Dizze opsje waard lansearre yn july. De swierrichheden fan 'e oergong resultearren yn wat ûntefredenens ûnder de ferkeaper en de frontline, mar yn' e folgjende moanne wisten wy alle rûge rânen te ferwiderjen en in proses te meitsjen ûnder de teams. Wy hawwe no gearstalling troch commit en levering.
Yn augustus slagge it ús om de earste ynstallaasje fan in apart pakket op produksje te foltôgjen mei ús pipeline, en sûnt septimber, sûnder útsûndering, waarden alle ynstallaasjes fan yndividuele net-release-pakketten útfierd fia ús CD-ark. Dêrnjonken binne wy it slagge om in oandiel fan eigen taken te berikken yn 40% fan 'e release-komposysje mei in lytser team dan de ferkeaper - dit is in definityf súkses. De meast serieuze taak bleau - te sammeljen en ynstallearje de release.
De definitive oplossing: kumulative ynstallaasjepakketten
Wy begrepen perfekt goed dat it skriptearjen fan de ynstruksjes fan 'e ferkeaper in sa-sa automatisearring wie; wy moasten it proses sels opnij betinke. De oplossing wie fanselssprekkend - om in kumulatyf oanbod te sammeljen fan 'e frijlittingstûke mei alle objekten fan' e fereaske ferzjes.
Wy begûnen mei proof of concept: wy hawwe it releasepakket mei de hân gearstald neffens de ynhâld fan 'e ferline ymplemintaasje en ynstalleare it op ús omjouwings. Alles slagge, it konsept bliek leefber te wêzen. Folgjende hawwe wy it probleem oplost fan it skript fan de initialisaasjeynstellingen en opnimme se yn 'e commit. Wy hawwe in nij pakket taret en testen yn testomjouwings as ûnderdiel fan 'e kontoerupdate. De ynstallaasje wie suksesfol, al mei in breed oanbod fan opmerkings fan it ymplemintaasjeteam. Mar it wichtichste is dat wy it startsein krigen om yn 'e release fan novimber mei ús gearkomste yn produksje te gean.
Mei krekt mear as in moanne oer, lieten de mei de hân útsochte foarrieden dúdlik oan dat de tiid út wie. Se besleaten de bou te meitsjen fan 'e frijlitting, mar wêrom soe it skieden wurde? Wy hawwe gjin Prod-like, en besteande tûken binne net goed - d'r is in protte ûnnedige koade. Wy moatte driuwend prod-likes besunigje, en dit is mear dan trije tûzen commits. It gearstallen mei de hân is hielendal gjin opsje. Wy sketste in skript dat rint troch it produkt ynstallaasje log en sammelet commits oan de tûke. De tredde kear wurke it goed, en nei "finish mei in triem" wie de tûke klear.
Wy hawwe ús eigen bouwer skreaun foar it ynstallaasjepakket en hawwe it yn in wike foltôge. Dan moasten wy de ynstallearder wizigje fan 'e kearnfunksjonaliteit fan it systeem, om't it iepen boarne is. Nei in searje kontrôles en oanpassingen waard it resultaat as suksesfol beskôge. Yn 'e tuskentiid krige de gearstalling fan' e release foarm, foar de juste ynstallaasje wêrfan it nedich wie om it testcircuit mei de produksje te rjochtsjen, en dêrfoar waard in apart skript skreaun.
Fansels wiene d'r in protte opmerkingen oer de earste ynstallaasje, mar oer it algemien wurke de koade. En nei sawat de tredde ynstallaasje begon alles goed te sjen. Gearstallingskontrôle en ferzjekontrôle fan objekten waarden apart kontrolearre yn 'e hânmjittige modus, dy't op dit stadium frij rjochtfeardich wie.
In ekstra útdaging wie it grutte tal net-útjeften dêr't rekken mei hâlden wurde moast. Mar mei de Prod-like branch en Rebase waard de taak transparant.
Earste kear, fluch en sûnder flaters
Wy benadere de frijlitting mei in optimistyske hâlding en mear as in tsiental suksesfolle ynstallaasjes op ferskate circuits. Mar letterlik in dei foar de deadline die bliken dat de ferkeaper it wurk net foltôge hie om de frijlitting foar ynstallaasje op 'e akseptearre manier te meitsjen. As om ien of oare reden ús build net wurket, sil de release fersteurd wurde. Boppedat, troch ús ynspannings, dat is benammen onaangenaam. Wy hiene gjin manier om werom te gean. Dêrom tochten wy troch alternative opsjes, makke aksjeplannen en begûnen ynstallaasje.
Ferrassend is de folsleine release, besteande út mear as 800 objekten, goed begon, de earste kear en yn mar 10 minuten. Wy hawwe in oere trochbrocht oan it kontrolearjen fan de logs op syk nei flaters, mar fûnen gjin.
De hiele oare deis wie d'r stilte yn 'e releasechat: gjin ymplemintaasjeproblemen, kromke ferzjes of "ûngeskikte" koade. It wie sels op ien of oare manier ûnhandich. Letter ferskynden guon opmerkingen, mar yn ferliking mei oare systemen en eardere ûnderfining wiene har oantal en prioriteit merkber leger.
In ekstra effekt fan it kumulative effekt wie in ferheging fan 'e kwaliteit fan gearstalling en testen. Fanwegen meardere ynstallaasjes fan 'e folsleine frijlitting waarden bouwdefekten en ynsetflaters op 'e tiid identifisearre. Testen yn konfiguraasjes foar folsleine frijlitting makke it mooglik om ek defekten te identifisearjen yn 'e ûnderlinge ynfloed fan objekten dy't net ferskynden tidens inkrementele ynstallaasjes. It wie grif in súkses, foaral sjoen ús 57% bydrage oan de frijlitting.
Resultaten en konklúzjes
Yn minder dan in jier wisten wy:
- Bou in folweardige ynterne ûntwikkeling mei in eksoatysk systeem;
- Eliminearje krityske ferkeaperôfhinklikens;
- Launch CI / CD foar in hiel unfriendly legacy;
- Ferheegje ymplemintaasjeprosessen nei in nij technysk nivo;
- Ferminderje ynsettiid signifikant;
- Ferminderje it oantal ymplemintaasjeflaters signifikant;
- Ferklearje josels mei fertrouwen as in liedende ûntwikkelingsekspert.
Fansels liket in protte fan wat beskreaun wurdt as direkte crap, mar dit binne de skaaimerken fan it systeem en de prosesbeperkingen dy't deryn besteane. Op it stuit hawwe de wizigingen ynfloed op produkten en tsjinsten fan IS-profyl (masterakkounts, plestikkaarten, sparakkounts, escrow, cashlieningen), mar mooglik kin de oanpak tapast wurde op elke IS wêrfoar de taak fan ymplemintaasje fan DevOps-praktiken is ynsteld. It kumulative model kin feilich replikearre wurde foar folgjende ymplemintaasjes (ynklusyf net-release) fan in protte leveringen.
Boarne: www.habr.com