DevOps-praktikoj funkcias. Pri tio ni mem konvinkiĝis, kiam ni reduktis la eldoninstaladan tempon je 10 fojojn. En la FIS Profile-sistemo, kiun ni uzas ĉe VTB, instalado nun daŭras 90 minutojn prefere ol 10. La eldona konstrutempo malpliiĝis de du semajnoj al du tagoj. La nombro da persistaj efektivigdifektoj falis al preskaŭ minimumo. Por foriri de "mana laboro" kaj forigi dependecon de la vendisto, ni devis labori per lambastonoj kaj trovi neatenditajn solvojn. Sub la tranĉo estas detala rakonto pri kiel ni konstruis plenan internan disvolviĝon.
Prologo: DevOps estas filozofio
Dum la pasinta jaro, ni multe laboris por organizi la internan disvolviĝon kaj efektivigon de DevOps-praktikoj ĉe VTB:
- Ni konstruis internajn evoluajn procezojn por 12 sistemoj;
- Ni lanĉis 15 duktoj, kvar el kiuj estis alportitaj al produktado;
- Aŭtomatigitaj 1445 testscenaroj;
- Ni sukcese efektivigis kelkajn eldonojn preparitajn de endomaj teamoj.
Unu el la plej malfacilaj organizi internan disvolviĝon kaj efektivigon de DevSecOps-praktikoj montriĝis esti la FIS Profile-sistemo - podetala produktoprocesoro sur ne-rilata DBMS. Tamen, ni povis konstrui la evoluon, lanĉi la dukton, instali individuajn ne-eldonajn pakaĵojn sur la produkto kaj lernis kiel kunmeti eldonojn. La tasko ne estis facila, sed interesa kaj sen evidentaj limigoj en efektivigo: jen la sistemo - vi devas konstrui internan disvolviĝon. La sola kondiĉo estas uzi la KD antaŭ produktiva medio.
Komence, la efektiviga algoritmo ŝajnis simpla kaj klara:
- Ni disvolvas komencan disvolvan kompetentecon kaj atingas akcepteblan nivelon de kvalito de la koda teamo sen krudaj difektoj;
- Ni integriĝas en ekzistantajn procezojn kiel eble plej multe;
- Por transdoni kodon inter evidentaj etapoj, ni tranĉas dukton kaj puŝas unu el ĝiaj finoj en la daŭrigon.
Dum ĉi tiu tempo, la disvolva teamo de la bezonata grandeco devas evoluigi kapablojn kaj pliigi la parton de sia kontribuo al eldonoj al akceptebla nivelo. Kaj jen ĝi, ni povas konsideri la taskon finita.
Ŝajnus, ke ĉi tio estas tute energiefika vojo al la bezonata rezulto: jen DevOps, jen la agado de la teamo, jen la amasigita kompetenteco... Sed praktike ni ricevis alian konfirmon, ke DevOps ankoraŭ temas pri filozofio. , kaj ne "alkroĉita al la gitlab-procezo, ansible, interplektaĵo kaj pli malsupre en la listo."
Denove analizinte la agadplanon, ni rimarkis, ke ni konstruas en ni mem specon de subkontraktado. Tial, proceza reinĝenierado estis aldonita al la algoritmo priskribita supre, same kiel la evoluo de kompetenteco laŭ la tuta evoluitinero por atingi gvidan rolon en ĉi tiu procezo. Ne la plej facila opcio, sed ĉi tiu estas la vojo de ideologie ĝusta evoluo.
Kie komenciĝas interna disvolviĝo?
Ĝi ne estis la plej amika sistemo por labori. Arkitekture, ĝi estis unu granda ne-rilata DBMS, konsistis el multaj apartaj plenumeblaj objektoj (skriptoj, proceduroj, aroj, ktp.), kiuj estis nomitaj laŭbezone, kaj funkciis laŭ la principo de nigra skatolo: ĝi ricevas peton kaj temojn. respondo. Aliaj malfacilaĵoj atentindaj inkluzivas:
- Ekzota lingvo (MUMPS);
- Konzola interfaco;
- Manko de integriĝo kun popularaj aŭtomatigaj iloj kaj kadroj;
- Volumo de datumoj en dekoj da terabajtoj;
- Ŝarĝo de pli ol 2 milionoj da operacioj hore;
- Signifeco - Komerco-Kritika.
Samtempe, ne estis fontkoda deponejo ĉe nia flanko. Entute. Estis dokumentaro, sed ĉiuj ŝlosilaj scio kaj kompetentecoj estis flanke de ekstera organizo.
Ni komencis regi la disvolviĝon de la sistemo preskaŭ de nulo, konsiderante ĝiajn funkciojn kaj malaltan distribuon. Komencite en oktobro 2018:
- Studis la dokumentadon kaj bazojn de kodgenerado;
- Ni studis la mallongan kurson pri evoluo ricevita de la vendisto;
- Majstri komencajn evoluajn kapablojn;
- Ni kompilis trejnan manlibron por novaj teamanoj;
- Ni konsentis inkluzivi la teamon en "batala" reĝimo;
- Solvis la problemon kun koda kvalitkontrolo;
- Ni organizis standon por evoluo.
Ni pasigis tri monatojn disvolvante kompetentecon kaj mergante nin en la sistemo, kaj ekde la komenco de 2019, interna disvolviĝo komencis sian movadon al brila estonteco, foje malfacile, sed memfide kaj celkonscie.
Deponejo migrado kaj aŭtotestoj
La unua tasko DevOps estas la deponejo. Ni rapide konsentis pri disponigado de aliro, sed necesis migri de la nuna SVN kun unu trunka branĉo al nia celo Git kun la transiro al modelo de pluraj branĉoj kaj disvolviĝo de Git Flow. Ni ankaŭ havas 2 teamojn kun sia propra infrastrukturo, krom parto de la teamo de la vendisto eksterlande. Mi devis vivi kun du Gits kaj certigi sinkronigon. En tia situacio, ĝi estis la pli malgranda el du malbonoj.
La migrado de la deponejo estis plurfoje prokrastita; ĝi estis kompletigita nur en aprilo, kun la helpo de kolegoj de la unua linio. Kun Git Flow, ni decidis teni la aferojn simplaj por komenci kaj decidiĝis laŭ la klasika skemo kun varmego, disvolvi kaj liberigi. Ili decidis forlasi majstron (alinome prod-similan). Malsupre ni klarigos kial ĉi tiu opcio montriĝis optimuma por ni. Ekstera deponejo apartenanta al la vendisto, ofta por du teamoj, estis utiligita kiel laboristo. Ĝi sinkronigis kun la interna deponejo laŭ horaro. Nun kun Git kaj Gitlab eblis aŭtomatigi procezojn.
La afero de aŭtotestoj estis solvita surprize facile - ni ricevis pretan kadron. Konsiderante la proprecojn de la sistemo, voki apartan operacion estis komprenebla parto de la komerca procezo kaj samtempe servis kiel unutesto. Restis nur prepari la testajn datumojn kaj agordi la deziratan ordon voki la skriptojn kaj taksi la rezultojn. Dum la listo de scenaroj, formita surbaze de operaciaj statistikoj, la kritikeco de procezoj kaj la ekzistanta regresa metodaro, pleniĝis, aŭtomataj testoj komencis aperi. Nun ni povus komenci konstrui la dukton.
Kiel ĝi estis: la modelo antaŭ aŭtomatigo
La ekzistanta modelo de la efektivigprocezo estas aparta rakonto. Ĉiu modifo estis mane transdonita kiel aparta pliiga instalpakaĵo. Poste venis mana registrado en Jira kaj mana instalado sur medioj. Por individuaj pakaĵoj, ĉio aspektis klara, sed kun la preparado de la liberigo, aferoj estis pli komplikaj.
Kunigo estis efektivigita je la nivelo de individuaj liveraĵoj, kiuj estis sendependaj objektoj. Ajna ŝanĝo estas nova livero. Interalie, 60-70 teknikaj versioj estis aldonitaj al la 10-15 pakaĵoj de la ĉefa eldonkonsisto - versioj akiritaj aldonante aŭ ekskludante ion de la eldono kaj reflektante ŝanĝojn en vendo ekster eldonoj.
Objektoj ene de la liveraĵoj interkovris unu kun la alia, precipe en la plenumebla kodo, kiu estis malpli ol duono unika. Estis multaj dependecoj kaj de la jam instalita kodo kaj de tiu, kies instalado estis ĵus planita.
Por akiri la bezonatan version de la kodo, estis necese strikte sekvi la instalan ordon, dum kiu objektoj estis fizike reverkitaj multfoje, proksimume 10-12 fojojn.
Post instalo de aro da pakaĵoj, mi devis permane sekvi instrukciojn por pravalorigi la agordojn. La liberigo estis kunvenita kaj instalita fare de la vendisto. La komponado de la eldono estis klarigita preskaŭ antaŭ la momento de efektivigo, kio implicis la kreadon de "malkunligaj" pakaĵoj. Kiel rezulto, signifa parto de la provizoj moviĝis de liberigo al liberigo kun sia propra vosto de "malligadoj".
Nun estas klare, ke kun ĉi tiu aliro - kunmeti la liberenigmon ĉe la paknivelo - ununura majstra branĉo havis neniun praktikan signifon. Instalado dum produktado daŭris de unu kaj duono ĝis du horoj da manlaboro. Estas bone, ke almenaŭ ĉe la instalilo-nivelo la ordo de objektoprilaborado estis specifita: kampoj kaj strukturoj estis enigitaj antaŭ la datumoj por ili kaj proceduroj. Tamen ĉi tio nur funkciis ene de aparta pakaĵo.
La logika rezulto de ĉi tiu aliro estis la devigaj instalaĵdifektoj en la formo de kurbaj versioj de objektoj, nenecesa kodo, mankantaj instrukcioj kaj nekalkulitaj reciprokaj influoj de objektoj, kiuj estis febre forigitaj post liberigo.
Unuaj ĝisdatigoj: fari muntadon kaj liveron
Aŭtomatigo komenciĝis elsendante kodon tra tubo laŭ ĉi tiu itinero:
- Prenu la finitan liveraĵon el stokado;
- Instalu ĝin sur dediĉita medio;
- Ruli aŭtotestojn;
- Taksi la rezulton de la instalado;
- Voku la sekvan dukton ĉe la flanko de la testa komando.
La sekva dukto devus registri la taskon en Jira kaj atendi ke komandoj estu distribuitaj al elektitaj testaj bukloj, kiuj dependas de la tempo de la tasko efektivigo. Trigger - letero pri preteco por livero al difinita adreso. Ĉi tio, kompreneble, estis evidenta lambastono, sed mi devis ie komenci. En majo 2019, la translokigo de kodo komenciĝis per kontroloj pri niaj medioj. La procezo komenciĝis, restas nur alporti ĝin en decan formon:
- Ĉiu modifo estas farita en aparta branĉo, kiu respondas al la instalaĵa pako kaj kunfandiĝas en la celan majstran branĉon;
- La dukto lanĉa ellasilo estas la apero de nova komit en la majstra branĉo per kunfanda peto, kiu estas fermita de prizorgantoj de la interna teamo;
- Deponejoj estas sinkronigitaj unufoje ĉiujn kvin minutojn;
- La muntado de la instalaĵo estas komencita - uzante la asembleron ricevitan de la vendisto.
Post ĉi tio, estis jam ekzistantaj paŝoj por kontroli kaj translokigi la kodon, por lanĉi la tubon kaj kunveni nianflanke.
Ĉi tiu opcio estis lanĉita en julio. La malfacilaĵoj de la transiro rezultigis iom da malkontento inter la vendisto kaj la unua linio, sed dum la sekva monato ni sukcesis forigi ĉiujn malglatajn randojn kaj establi procezon inter la teamoj. Ni nun havas asembleon per kompromiso kaj livero.
En aŭgusto, ni sukcesis kompletigi la unuan instaladon de aparta pakaĵo en produktado per nia dukto, kaj ekde septembro, senescepte, ĉiuj instalaĵoj de individuaj ne-eldonaj pakaĵoj estis faritaj per nia KD-ilo. Krome, ni sukcesis atingi parton de internaj taskoj en 40% de la eldonkonsisto kun pli malgranda teamo ol la vendisto - ĉi tio estas certa sukceso. La plej serioza tasko restis - kunveni kaj instali la liberigon.
La fina solvo: akumulaj instalaj pakoj
Ni perfekte komprenis, ke skribi la instrukciojn de la vendisto estis tiel tiel aŭtomatigo; ni devis repripensi la procezon mem. La solvo estis evidenta - kolekti akumulan provizon de la eldona branĉo kun ĉiuj objektoj de la bezonataj versioj.
Ni komencis kun pruvo de koncepto: ni mane kunmetis la eldonpakaĵon laŭ la enhavo de la pasinta efektivigo kaj instalis ĝin en niaj medioj. Ĉio funkciis, la koncepto montriĝis farebla. Poste, ni solvis la problemon pri skribado de la komencaj agordoj kaj inkluzivi ilin en la kommit. Ni preparis novan pakaĵon kaj testis ĝin en testaj medioj kiel parto de la kontura ĝisdatigo. La instalado estis sukcesa, kvankam kun larĝa gamo de komentoj de la efektivigteamo. Sed la ĉefa afero estas, ke ni ricevis la permeson eniri en produktadon en la novembra eldono kun nia asembleo.
Kun iom pli ol monato restanta, la mane elektitaj provizoj klare sugestis, ke tempo finiĝas. Ili decidis fari la konstruon de la eldonbranĉo, sed kial ĝi estu apartigita? Ni ne havas Prod-similan, kaj ekzistantaj branĉoj ne estas bonaj - estas multe da nenecesa kodo. Ni urĝe bezonas tranĉi prod-ŝatojn, kaj ĉi tio estas pli ol tri mil kommitaĵoj. Muntado permane tute ne estas eblo. Ni skizis skripton, kiu trairas la protokolon de instalo de la produkto kaj kolektas komitojn al la branĉo. La trian fojon ĝi funkciis ĝuste, kaj post "fino per dosiero" la branĉo estis preta.
Ni skribis nian propran konstruilon por la instala pako kaj finis ĝin en semajno. Tiam ni devis modifi la instalilon de la kerna funkcio de la sistemo, ĉar ĝi estas malfermfonta. Post serio de kontroloj kaj modifoj, la rezulto estis konsiderita sukcesa. Intertempe formiĝis la komponado de la eldonaĵo, por kies ĝusta instalado necesis vicigi la provan cirkviton kun la produktada, kaj por tio estis skribita aparta skripto.
Kompreneble, estis multaj komentoj pri la unua instalado, sed ĝenerale la kodo funkciis. Kaj post ĉirkaŭ la tria instalado ĉio komencis aspekti bone. Kontrolo de komponado kaj kontrolo de versio de objektoj estis monitoritaj aparte en mana reĝimo, kio en ĉi tiu etapo estis sufiĉe pravigita.
Kroma defio estis la granda nombro da ne-eldonaĵoj kiuj devis esti enkalkulitaj. Sed kun la Prod-simila branĉo kaj Rebase, la tasko iĝis travidebla.
Unuafoje, rapide kaj sen eraroj
Ni alproksimiĝis al la eldono kun optimisma sinteno kaj pli ol deko da sukcesaj instalaĵoj sur malsamaj cirkvitoj. Sed laŭvorte tagon antaŭ la limdato, montriĝis, ke la vendisto ne finis la laboron por prepari la liberigon por instalado laŭ la akceptita maniero. Se ial nia konstruo ne funkcias, la liberigo estos interrompita. Cetere, per niaj klopodoj, kio estas precipe malagrabla. Ni ne havis manieron retiriĝi. Tial ni pripensis alternativajn eblojn, preparis agadplanojn kaj komencis instaladon.
Surprize, la tuta eldono, konsistanta el pli ol 800 objektoj, komenciĝis ĝuste, la unuan fojon kaj en nur 10 minutoj. Ni pasigis horon kontrolante la protokolojn serĉante erarojn, sed ne trovis.
La tutan sekvan tagon estis silento en la eldona babilejo: neniuj efektivigproblemoj, malrektaj versioj aŭ "malkonvena" kodo. Estis eĉ iel mallerte. Poste aperis kelkaj komentoj, sed kompare kun aliaj sistemoj kaj antaŭaj spertoj, ilia nombro kaj prioritato estis rimarkeble pli malaltaj.
Kroma efiko de la akumula efiko estis pliiĝo en la kvalito de kunigo kaj testado. Pro multoblaj instalaĵoj de la plena eldono, konstrudifektoj kaj deplojeraroj estis identigitaj ĝustatempe. Testado en plenaj eldonaj agordoj ebligis aldone identigi difektojn en la reciproka influo de objektoj, kiuj ne aperis dum pliigaj instalaĵoj. Ĝi estis sendube sukceso, precipe pro nia 57% kontribuo al la liberigo.
Rezultoj kaj konkludoj
En malpli ol unu jaro ni sukcesis:
- Konstruu plenan internan disvolviĝon uzante ekzotikan sistemon;
- Forigi kritikan dependecon de vendisto;
- Lanĉu CI/KD por tre malafabla heredaĵo;
- Levu efektivigajn procezojn al nova teknika nivelo;
- Signife redukti la tempon de deplojo;
- Signife redukti la nombron da efektivigaj eraroj;
- Memfide deklaru vin kiel plej elstara disvolva fakulo.
Kompreneble, multe de tio, kio estas priskribita, aspektas kiel tute aĉa, sed ĉi tiuj estas la trajtoj de la sistemo kaj la procezaj limigoj, kiuj ekzistas en ĝi. Nuntempe, la ŝanĝoj influis produktojn kaj servojn de IS Profile (majstraj kontoj, plastaj kartoj, ŝparkontoj, escrow, kontantpruntoj), sed eble la aliro povas esti aplikita al iu ajn IS por kiu la tasko efektivigi DevOps-praktikojn estas fiksita. La akumula modelo povas esti sekure reproduktita por postaj efektivigoj (inkluzive de ne-liberigaj) de multaj liveraĵoj.
fonto: www.habr.com