E pratiche di DevOps funzionanu. Eramu cunvinti di questu quandu avemu riduciutu u tempu di stallazione di liberazione per 10 volte. In u sistema di Profile FIS, chì avemu usatu in VTB, a stallazione avà pigghia 90 minuti invece di 10. U tempu di creazione di liberazione hè diminuitu da duie simane à dui ghjorni. U numaru di difetti persistenti di implementazione hè cascatu à quasi u minimu. Per alluntanassi da u "travagliu manuale" è eliminà a dependenza di u vinditore, avemu avutu à travaglià cù crutches è truvà suluzioni inespettate. Sottu u cut hè una storia dettagliata di cumu avemu custruitu un sviluppu internu cumpletu.
Prologue: DevOps hè una filusufìa
L'annu passatu, avemu fattu assai travagliu per urganizà u sviluppu internu è l'implementazione di e pratiche DevOps in VTB:
- Avemu custruitu prucessi di sviluppu internu per i sistemi 12;
- Avemu lanciatu 15 pipelines, quattru di quali sò stati purtati à a pruduzzione;
- 1445 scenarii di teste automatizati;
- Avemu implementatu cù successu una quantità di versioni preparate da e squadre interne.
Unu di i più difficiuli di urganizà u sviluppu inhouse è l'implementazione di e pratiche DevSecOps hè statu u sistema FIS Profile - un processore di produttu di vendita in un DBMS non-relazionale. Tuttavia, avemu statu capaci di custruisce u sviluppu, lancià u pipeline, installà pacchetti individuali senza liberazione nantu à u pruduttu, è hà amparatu cumu assemble e versioni. U compitu ùn era micca faciule, ma interessante è senza restrizioni evidenti in l'implementazione: quì hè u sistema - avete bisognu di custruisce un sviluppu in-house. L'unica cundizione hè di utilizà u CD prima di un ambiente produtivu.
À u principiu, l'algoritmu di implementazione pareva simplice è chjaru:
- Sviluppemu una cumpetenza di sviluppu iniziale è ottene un livellu accettabile di qualità da a squadra di codice senza difetti grossi;
- Integremu in i prucessi esistenti quant'è pussibule;
- Per trasfirià u codice trà e tappe evidenti, avemu tagliatu un pipeline è spinghje unu di i so fini in a continuazione.
Duranti stu tempu, a squadra di sviluppu di a dimensione necessaria deve sviluppà e cumpetenze è aumentà a parte di a so cuntribuzione à e versioni à un livellu accettabile. È questu hè, pudemu cunsiderà u compitu finitu.
Sembra chì questu hè un percorsu cumplettamente efficiente in energia per u risultatu necessariu: quì hè DevOps, quì sò e metriche di rendiment di a squadra, quì hè a cumpetenza accumulata... Ma in pratica, avemu ricevutu una altra cunferma chì DevOps hè sempre di filusufìa. , è micca "attached to the gitlab process, ansible, nexus and more down the list".
Dopu avè una volta analizatu u pianu d'azzione, avemu capitu chì stavamu custruendu una spezia di venditore di outsourcing in noi stessi. Dunque, a reingegneria di u prucessu hè stata aghjunta à l'algoritmu descrittu sopra, è ancu u sviluppu di l'expertise in tutta a strada di sviluppu per ottene un rolu di primura in stu prucessu. Ùn hè micca l'opzione più faciule, ma questu hè u percorsu di u sviluppu ideologicu currettu.
Induve principia u sviluppu inhouse?
Ùn era micca u sistema più amichevule per travaglià. Architecturally, era un grande DBMS non-relazionale, custituitu di parechji ogetti eseguibili separati (scripts, prucedure, batch, etc.), chì sò stati chjamati cum'è necessariu, è hà travagliatu nantu à u principiu di una scatula negra: riceve una dumanda è prublemi. una risposta. Altre difficultà da nutà include:
- lingua esotica (MUMPS);
- interfaccia di cunsola;
- Mancanza di integrazione cù l'arnesi di l'automatizazione populari è i quadri;
- Volume di dati in decine di terabytes;
- Carica di più di 2 milioni di operazioni per ora;
- Significance - Business-Critical.
À u listessu tempu, ùn ci era micca un repository di codice fonte da u nostru latu. Per nunda. Ci era a documentazione, ma tutte e cunniscenze è e cumpetenze chjave eranu da u latu di una urganizazione esterna.
Avemu cuminciatu à maestru di u sviluppu di u sistema quasi da zero, tenendu in contu e so caratteristiche è a distribuzione bassa. Accuminciatu in uttrovi 2018:
- Studiatu a documentazione è i principii di a generazione di codice;
- Avemu studiatu u cursu curtu nantu à u sviluppu ricevutu da u venditore;
- Cumpetenze di sviluppu iniziale maestru;
- Avemu cumpilatu un manuale di furmazione per i novi membri di a squadra;
- Avemu accunsentutu à includà a squadra in u modu "combattimentu";
- Risolta u prublema cù u cuntrollu di qualità di codice;
- Avemu urganizatu un stand per u sviluppu.
Avemu passatu trè mesi à sviluppà sapè è immerse in u sistema, è da u principiu di u 2019, u sviluppu inhouse hà iniziatu u so muvimentu versu un futuru luminoso, à volte cù difficultà, ma cun fiducia è intentu.
Migrazione di repository è autotest
U primu compitu DevOps hè u repository. Avemu accunsentutu rapidamente à furnisce l'accessu, ma era necessariu di migrà da u SVN attuale cù un ramu di troncu à u nostru destinazione Git cù a transizione à un mudellu di parechje rami è u sviluppu di Git Flow. Avemu ancu 2 squadre cù a so propria infrastruttura, più una parte di a squadra di u venditore à l'esteru. Aviu avutu à campà cù dui Gits è assicurà a sincronizazione. In una tale situazione, era u più chjucu di dui mali.
A migrazione di u repositoriu hè stata ripetutamente posposta; hè stata cumpletata solu in April, cù l'aiutu di i culleghi di prima linea. Cù Git Flow, avemu decisu di mantene e cose simplici per un principiu è stallate nantu à u schema classicu cù hotfix, sviluppà è liberate. Anu decisu di abbandunà u maestru (aka prod-like). Quì sottu spiegheremu perchè sta opzione hè stata ottima per noi. Un repositoriu esternu chì appartene à u vinditore, cumunu per duie squadre, hè stata utilizata cum'è travagliadore. Hè sincronizatu cù u repositoriu internu secondu un schedariu. Avà cù Git è Gitlab era pussibule di automatizà i prucessi.
U prublema di l'autotests hè stata risolta sorprendentemente facilmente - ci sò stati furniti cun un framework prontu. In cunsiderà e peculiarità di u sistema, chjamà una operazione separata era una parte comprensibile di u prucessu di l'affari è à u stessu tempu servia cum'è una prova di unità. Il ne restait plus qu'à préparer les données de test et à définir l'ordre souhaité de clamer les scripts et d'évaluer les résultats. Cum'è a lista di scenarii, furmati nantu à a basa di statistiche di u funziunamentu, a criticità di i prucessi è a metodulugia di regressione esistenti, cuminciò, i testi automatichi cuminciaru à apparisce. Avà pudemu cumincià à custruisce u pipeline.
Cumu era: u mudellu prima di l'automatizazione
U mudellu esistenti di u prucessu di implementazione hè una storia separata. Ogni mudificazione hè stata trasferita manualmente cum'è un pacchettu di installazione incrementale separatu. A seguita hè stata a registrazione manuale in Jira è a stallazione manuale in ambienti. Per i pacchetti individuali, tuttu pareva chjaru, ma cù a preparazione di a liberazione, e cose eranu più complicate.
L'assemblea hè stata realizata à u livellu di spedizioni individuali, chì eranu oggetti indipendenti. Ogni cambiamentu hè una nova consegna. Frà altre cose, e versioni tecniche 60-70 sò state aghjunte à i pacchetti 10-15 di a cumpusizioni di liberazione principale - versioni ottenute quandu aghjunghjenu o escludendu qualcosa da a liberazione è riflettendu cambiamenti in vendita fora di e versioni.
L'uggetti in e spedizioni si sovrapponevanu l'un à l'altru, in particulare in u codice eseguibile, chì era menu di a mità unicu. Ci era parechje dependenzii à u codice digià stallatu è à quellu chì a so installazione hè stata appena pianificata.
Per ottene a versione necessaria di u codice, era necessariu di seguità strettamente l'ordine di stallazione, durante quale l'uggetti sò stati riscritti fisicamenti parechje volte, circa 10-12 volte.
Dopu avè installatu un batch of packages, aghju avutu à seguità manualmente l'istruzzioni per inizializà i paràmetri. A liberazione hè stata assemblata è installata da u venditore. A cumpusizioni di a liberazione hè stata chjarificata quasi prima di u mumentu di l'implementazione, chì implicava a creazione di pacchetti "decoupling". In u risultatu, una parte significativa di i pruvisti si trasfirìu da a liberazione à a liberazione cù a so propria cuda di "decouplings".
Avà hè chjaru chì cù questu approcciu - assemblendu u puzzle di liberazione à u livellu di u pacchettu - una sola branca maestru ùn avia micca significatu praticu. A stallazione nantu à a pruduzzione hà pigliatu da una è mezza à duie ore di travagliu manuale. Hè bonu chì almenu à u nivellu di l'installatore l'ordine di u prucessu di l'ughjettu hè statu specificatu: i campi è e strutture sò stati inseriti prima di e dati per elli è e prucedure. Tuttavia, questu hà travagliatu solu in un pacchettu separatu.
U risultatu lògicu di sta dimarchja era i difetti di stallazione ubligatoriu in a forma di versioni crooked di l'uggetti, codice innecessariu, struzzioni mancanti è influenze mutuali di l'uggetti, chì eranu febbrilmente eliminati dopu a liberazione.
Primi aghjurnamenti: cumminciate l'assemblea è a consegna
L'automatizazione hà cuminciatu trasmettendu u codice attraversu una pipa longu à sta strada:
- Pigliate a consegna finita da u almacenamentu;
- Installa lu in un ambiente dedicatu;
- Eseguite autotests;
- Evaluate u risultatu di a stallazione;
- Chjamate a seguente pipeline à u latu di u cumandamentu di prova.
U prossimu pipeline deve registrà u compitu in Jira è aspittà chì i cumandamenti sò distribuiti à i loops di prova selezziunati, chì dipendenu da u timing di l'implementazione di u compitu. Trigger - una lettera nantu à a preparazione per a consegna à un indirizzu datu. Questu, sicuru, era una crutch evidenti, ma aghju avutu da principià in qualchì locu. In maghju 2019, u trasferimentu di codice hà cuminciatu cù cuntrolli nantu à i nostri ambienti. U prucessu hè principiatu, tuttu ciò chì resta hè di mette in forma decente:
- Ogni mudificazione hè realizatu in un ramu separatu, chì currisponde à u pacchettu di installazione è si unisce à u ramu maestru di destinazione;
- U trigger di lanciamentu di pipeline hè l'apparizione di un novu impegnu in u ramu maestru per mezu di una dumanda di fusione, chì hè chjusa da i mantenitori da a squadra interna;
- I repositori sò sincronizati una volta ogni cinque minuti;
- L'assemblea di u pacchettu di stallazione hè iniziata - utilizendu l'assembler ricevutu da u venditore.
Dopu à quessa, ci era digià esistenti passi à verificà è trasfiriri u codice, à lanciari u pipa è assemblà nant'à u nostru latu.
Questa opzione hè stata lanciata in lugliu. E difficultà di a transizione anu risultatu in una certa insatisfazione trà u vinditore è a prima linea, ma in u mesi dopu avemu riesciutu à caccià tutte e scogliere è stabilisce un prucessu trà e squadre. Avemu avà assemblea per impegnu è consegna.
In Aostu, avemu riesciutu à compie a prima stallazione di un pacchettu separatu nantu à a pruduzzione cù a nostra pipeline, è da settembre, senza eccezzioni, tutte e installazioni di pacchetti individuali senza liberazione sò state realizate per mezu di u nostru strumentu CD. Inoltre, avemu riesciutu à ottene una parte di i travaglii interni in u 40% di a cumpusizioni di liberazione cù una squadra più chjuca di u venditore - questu hè un successu definitu. U compitu più seriu restava - per assemblà è stallà a liberazione.
A suluzione finale: pacchetti di installazione cumulativi
Avemu capitu bè chì scrive l'istruzzioni di u venditore era una automatizazione cusì cusì; avemu avutu à ripensà u prucessu stessu. A suluzione era ovvia - per cullà un suministru cumulativu da u ramu di liberazione cù tutti l'uggetti di e versioni richieste.
Avemu cuminciatu cù a prova di cuncettu: avemu assemblatu manualmente u pacchettu di liberazione secondu u cuntenutu di l'implementazione passata è l'avete installatu in i nostri ambienti. Tuttu hà travagliatu, u cuncettu hè diventatu viable. In seguitu, avemu risoltu u prublema di scripting i paràmetri di inizializazione è inclusi in u cummit. Avemu preparatu un novu pacchettu è pruvatu in ambienti di prova cum'è parte di l'aghjurnamentu di u contornu. A stallazione hè stata riescita, anche se cù una larga gamma di cumenti da u squadra di implementazione. Ma a cosa principal hè chì ci hè statu datu u permessu per andà in pruduzzione in a liberazione di nuvembre cù a nostra assemblea.
À pocu più di un mese, i pruvisti scelti manualmente indicavanu chjaramente chì u tempu era finitu. Anu decisu di fà a custruzione da u ramu di liberazione, ma perchè deve esse separatu? Ùn avemu micca un Prod-like, è e rami esistenti ùn sò micca bè - ci hè assai codice innecessariu. Avemu bisognu urgente di taglià i prod-likes, è questu hè più di trè mila impegni. Assemblage a manu ùn hè micca una opzione in tuttu. Avemu abbozzatu un script chì scorri à traversu u logu di installazione di u produttu è raccoglie l'impegni à u ramu. A terza volta hà travagliatu currettamente, è dopu "finitu cù un schedariu" u ramu era prontu.
Avemu scrittu u nostru propiu costruttore per u pacchettu di stallazione è l'avemu finitu in una settimana. Allora avemu avutu a mudificà l'installatore da a funziunalità core di u sistema, postu chì hè open-source. Dopu una seria di cuntrolli è mudificazioni, u risultatu hè cunsideratu successu. Intantu, a cumpusizioni di a liberazione hà pigliatu forma, per a stallazione curretta di quale era necessariu allineà u circuitu di prova cù a produzzione, è un script separatu hè statu scrittu per questu.
Naturalmente, ci era assai cumenti nantu à a prima stallazione, ma in generale u codice hà travagliatu. È dopu à a terza stallazione, tuttu hà cuminciatu à vede bè. U cuntrollu di a cumpusizioni è u cuntrollu di a versione di l'uggetti sò stati monitorati separatamente in modu manuale, chì in questa fase era abbastanza ghjustificatu.
Una sfida addiziale era u gran numaru di non-releases chì avianu da esse cunsideratu. Ma cù u ramu Prod-like è Rebase, u compitu hè diventatu trasparente.
Prima volta, rapidamente è senza errore
Avemu avvicinatu à a liberazione cun una attitudine ottimista è più di una decina di installazioni riesciuti in circuiti diffirenti. Ma littiralmenti un ghjornu prima di a data di scadenza, resultò chì u venditore ùn avia micca finitu u travagliu per preparà a liberazione per a stallazione in u modu accettatu. Se per una certa ragione a nostra custruzione ùn funziona micca, a liberazione serà disturbata. Inoltre, attraversu i nostri sforzi, chì hè soprattuttu dispiacevule. Ùn avemu avutu manera di ritruvà. Dunque, avemu pensatu à l'opzioni alternative, preparatu piani d'azzione è cuminciatu à a stallazione.
Sorprendentemente, tutta a liberazione, custituita da più di 800 oggetti, hà cuminciatu currettamente, a prima volta è in solu 10 minuti. Avemu passatu una ora à cuntrollà i logs chì cercanu errori, ma ùn truvamu micca.
Tuttu u ghjornu dopu ci hè statu silenziu in u chat di liberazione: senza prublemi di implementazione, versioni storte o codice "inappropriatu". Era ancu in una certa manera imbarazzante. In seguitu, alcuni cumenti emergenu, ma paragunatu à l'altri sistemi è a sperienza precedente, u so numeru è a priorità eranu notevolmente più bassi.
Un effettu supplementu da l'effettu cumulativu era un aumentu di a qualità di l'assemblea è di a prova. A causa di parechje installazioni di a liberazione completa, i difetti di custruzzione è l'errori di implementazione sò stati identificati in una manera puntuale. A prova in cunfigurazioni di liberazione cumpleta hà permessu di identificà ancu i difetti in l'influenza mutuale di l'uggetti chì ùn sò micca apparsu durante l'installazione incrementali. Hè stata definitivamente un successu, soprattuttu datu a nostra cuntribuzione di 57% à a liberazione.
Risultati è cunclusioni
In menu di un annu avemu riesciutu à:
- Custruisce un sviluppu internu cumpletu cù un sistema esoticu;
- Eliminate a dipendenza critica di u venditore;
- Lanciari CI/CD per un legatu assai antipaticu;
- Elevate i prucessi di implementazione à un novu livellu tecnicu;
- Reduce significativamente u tempu di implementazione;
- Reduce significativamente u numeru di errori di implementazione;
- Dichjarate cun fiducia cum'è un espertu di sviluppu di punta.
Di sicuru, assai di ciò chì hè descrittu s'assumiglia à una merda, ma queste sò e caratteristiche di u sistema è e limitazioni di u prucessu chì esistenu in questu. À u mumentu, i cambiamenti affettanu i prudutti è i servizii di u Profilu IS (conti maestri, carte di plastica, cunti di risparmiu, escrow, prestiti in cash), ma potenzialmente l'approcciu pò esse applicatu à qualsiasi IS per quale u compitu di implementà e pratiche DevOps hè stabilitu. U mudellu cumulativu pò esse replicatu in modu sicuru per implementazioni successive (inclusi quelli chì ùn sò micca liberati) da parechje spedizioni.
Source: www.habr.com