DevOps praktikos veikia. Tuo įsitikinome patys, kai 10 kartų sutrumpinome leidimo diegimo laiką. FIS Profile sistemoje, kurią naudojame VTB, diegimas dabar trunka 90 minučių, o ne 10. Išleidimo kūrimo laikas sutrumpėjo nuo dviejų savaičių iki dviejų dienų. Nuolatinių diegimo defektų skaičius sumažėjo iki beveik minimumo. Norėdami atsikratyti „rankinio darbo“ ir pašalinti priklausomybę nuo pardavėjo, turėjome dirbti su ramentais ir rasti netikėtų sprendimų. Po pjūviu pateikiama išsami istorija apie tai, kaip sukūrėme visavertį vidinį vystymąsi.
Prologas: DevOps yra filosofija
Per pastaruosius metus nuveikėme daug darbo, organizuodami vidinį DevOps praktikų kūrimą ir diegimą VTB:
- Sukūrėme vidinius kūrimo procesus 12 sistemų;
- Paleidome 15 vamzdynų, iš kurių keturi pradėti gaminti;
- Automatizuoti 1445 bandymų scenarijai;
- Sėkmingai įdiegėme daugybę vidinių komandų paruoštų leidimų.
Vienas iš sunkiausiai organizuojamų DevSecOps praktikų kūrimą ir diegimą namuose buvo FIS Profile sistema – mažmeninės prekybos produktų procesorius nesusijusioje DBVS. Nepaisant to, mums pavyko sukurti plėtrą, paleisti konvejerį, įdiegti atskirus neišleistus paketus gaminyje ir išmokti surinkti leidimus. Užduotis nebuvo lengva, bet įdomi ir be akivaizdžių apribojimų įgyvendinant: štai sistema – reikia sukurti vidaus plėtrą. Vienintelė sąlyga yra naudoti kompaktinį diską prieš produktyvią aplinką.
Iš pradžių įgyvendinimo algoritmas atrodė paprastas ir aiškus:
- Mes plėtojame pirminę kūrimo patirtį ir iš kodų komandos pasiekiame priimtiną kokybės lygį be didelių defektų;
- Kiek įmanoma labiau integruojamės į esamus procesus;
- Norėdami perkelti kodą tarp akivaizdžių etapų, nupjauname dujotiekį ir vieną jo galą įstumiame į tęsinį.
Per šį laiką reikiamo dydžio kūrėjų komanda turi išsiugdyti įgūdžius ir padidinti savo indėlio dalį į leidimus iki priimtino lygio. Ir viskas, užduotį galime laikyti baigta.
Atrodytų, tai yra visiškai energiją taupantis kelias link reikiamo rezultato: čia DevOps, čia komandos veiklos metrika, čia sukaupta kompetencija... Tačiau praktiškai gavome dar vieną patvirtinimą, kad DevOps vis dar yra filosofija. , o ne „pririštas prie „gitlab“ proceso, ansible, nexus ir toliau sąraše.
Dar kartą išanalizavę veiksmų planą supratome, kad kuriame savotišką užsakomąjį pardavėją savyje. Todėl prie aukščiau aprašyto algoritmo buvo pridėtas proceso pertvarkymas, taip pat kompetencijos tobulinimas visame kūrimo kelyje, siekiant šiame procese atlikti pagrindinį vaidmenį. Ne pats lengviausias variantas, bet tai ideologiškai teisingos raidos kelias.
Kur prasideda vidinė plėtra?
Tai nebuvo pati draugiškiausia sistema dirbti. Architektūriškai tai buvo viena didelė nesusijusi DBVS, susidedanti iš daugybės atskirų vykdomųjų objektų (skriptų, procedūrų, paketų ir kt.), kurie buvo iškviečiami pagal poreikį ir veikė juodosios dėžės principu: gauna užklausą ir išduoda. atsakymas. Kiti sunkumai, į kuriuos verta atkreipti dėmesį, yra šie:
- Egzotiška kalba (MUMPS);
- konsolės sąsaja;
- Integracijos su populiariais automatizavimo įrankiais ir sistemomis trūkumas;
- Duomenų apimtis dešimtimis terabaitų;
- Daugiau nei 2 milijonų operacijų per valandą apkrova;
- Reikšmė – Verslui svarbi.
Tuo pačiu metu mūsų pusėje nebuvo šaltinio kodo saugyklos. Iš viso. Buvo dokumentai, bet visos pagrindinės žinios ir kompetencijos buvo išorinės organizacijos pusėje.
Sistemos kūrimą pradėjome įsisavinti beveik nuo nulio, atsižvelgdami į jos ypatybes ir žemą paskirstymą. Prasidėjo 2018 m. spalio mėn.:
- Išstudijavo dokumentaciją ir kodų generavimo pagrindus;
- Išstudijavome trumpą kursą apie plėtrą, gautą iš pardavėjo;
- Įvaldyti pirminio tobulėjimo įgūdžius;
- Sudarėme mokymo vadovą naujiems komandos nariams;
- Sutarėme įtraukti komandą į „kovinį“ režimą;
- Išspręsta kodo kokybės kontrolės problema;
- Surengėme stendą tobulėjimui.
Tris mėnesius tobulinome žinias ir pasinėrėme į sistemą, o nuo 2019-ųjų pradžios vidaus plėtra kartais sunkiai, bet užtikrintai ir kryptingai pradėjo judėti šviesios ateities link.
Saugyklų perkėlimas ir automatiniai testai
Pirmoji „DevOps“ užduotis yra saugykla. Greitai susitarėme dėl prieigos suteikimo, tačiau reikėjo pereiti nuo dabartinio SVN su viena magistraline šaka į tikslinį Git, pereinant prie kelių atšakų modelio ir plėtojant Git Flow. Taip pat turime 2 komandas su savo infrastruktūra, taip pat dalį pardavėjo komandos užsienyje. Turėjau gyventi su dviem Gitais ir užtikrinti sinchronizavimą. Esant tokiai situacijai, tai buvo mažesnė iš dviejų blogybių.
Kapinyno migracija buvo ne kartą atidėta, ji buvo baigta tik balandį, padedant kolegoms iš fronto linijos. Naudodami „Git Flow“ nusprendėme, kad pradžia būtų paprasta ir apsistojome prie klasikinės schemos su karštosiomis pataisomis, plėtojame ir išleidžiame. Jie nusprendė atsisakyti meistro (dar žinomo kaip prod). Žemiau paaiškinsime, kodėl ši parinktis mums pasirodė optimali. Pardavėjui priklausanti išorinė saugykla, bendra dviem komandoms, buvo naudojama kaip darbuotojas. Jis sinchronizuojamas su vidine saugykla pagal grafiką. Dabar su Git ir Gitlab buvo galima automatizuoti procesus.
Automatinių testų klausimas buvo išspręstas stebėtinai lengvai – mums buvo pateikta paruošta karkasa. Atsižvelgiant į sistemos ypatumus, atskiros operacijos iškvietimas buvo suprantama verslo proceso dalis ir kartu tarnavo kaip vienetinis testas. Liko tik paruošti testo duomenis ir nustatyti norimą scenarijų iškvietimo ir rezultatų vertinimo tvarką. Pildant scenarijų sąrašą, sudarytą remiantis veiklos statistika, procesų kritiškumu ir esama regresijos metodika, pradėjo atsirasti automatiniai testai. Dabar galime pradėti tiesti dujotiekį.
Kaip buvo: modelis prieš automatizavimą
Esamas įgyvendinimo proceso modelis yra atskira istorija. Kiekviena modifikacija buvo rankiniu būdu perkelta kaip atskiras laipsniškas diegimo paketas. Po to sekė rankinė registracija „Jira“ ir rankinis diegimas aplinkoje. Atskiroms pakuotėms viskas atrodė aišku, tačiau ruošiant leidimą viskas buvo sudėtingiau.
Surinkimas buvo atliktas atskirų pristatymų lygiu, kurie buvo nepriklausomi objektai. Bet koks pakeitimas yra naujas pristatymas. Be kita ko, į 60–70 pagrindinės leidimo sudėties paketų buvo pridėta 10–15 techninių versijų – versijos, gautos ką nors pridedant arba išbraukiant iš leidimo ir atspindinčios pardavimų pokyčius už leidimų ribų.
Pristatymuose esantys objektai sutapo vienas su kitu, ypač vykdomajame kode, kuris buvo mažiau nei pusė unikalaus. Buvo daug priklausomybių tiek nuo jau įdiegto kodo, tiek nuo to, kurio įdiegimas buvo ką tik suplanuotas.
Norint gauti reikiamą kodo versiją, reikėjo griežtai laikytis diegimo tvarkos, kurios metu objektai buvo fiziškai perrašomi daug kartų, kai kurie 10–12 kartų.
Įdiegęs paketų paketą, turėjau rankiniu būdu vadovautis instrukcijomis, kad inicijuotų nustatymus. Išleidimą surinko ir įdiegė pardavėjas. Išleidimo sudėtis buvo išaiškinta beveik prieš diegimo momentą, todėl buvo sukurti „atsiejami“ paketai. Dėl to nemaža dalis atsargų persikėlė iš išleidimo į išleidimą su savo „atjungimų“ uodega.
Dabar aišku, kad naudojant šį metodą – išleidimo galvosūkio surinkimą paketo lygiu – viena pagrindinė šaka neturėjo praktinės prasmės. Montavimas gamyboje užtruko nuo pusantros iki dviejų valandų rankų darbo. Gerai, kad bent jau montuotojo lygmenyje buvo nurodyta objektų apdorojimo tvarka: laukai ir struktūros buvo įvedamos prieš jų duomenis ir procedūras. Tačiau tai veikė tik atskirame pakete.
Logiškas tokio požiūrio rezultatas buvo privalomi diegimo defektai – kreivos objektų versijos, nereikalingas kodas, trūkstamos instrukcijos ir neįvertinta abipusė objektų įtaka, kurie karštligiškai buvo šalinami po išleidimo.
Pirmieji atnaujinimai: surinkti ir pristatyti
Automatizavimas prasidėjo perduodant kodą vamzdžiu šiuo maršrutu:
- Paimti gatavą siuntą iš sandėlio;
- Įdiekite jį tam skirtoje aplinkoje;
- Paleisti automatinius testus;
- Įvertinkite montavimo rezultatą;
- Iškvieskite šį dujotiekį testavimo komandos pusėje.
Kitas dujotiekis turėtų užregistruoti užduotį „Jira“ ir laukti, kol komandos bus paskirstytos pasirinktoms testavimo kilpoms, kurios priklauso nuo užduoties įgyvendinimo laiko. Trigeris – laiškas apie pasirengimą pristatyti nurodytu adresu. Tai, žinoma, buvo akivaizdus ramentas, bet turėjau kažkur pradėti. 2019 m. gegužės mėn. kodo perkėlimas prasidėjo patikrinus mūsų aplinką. Procesas prasidėjo, belieka jį įvesti į tinkamą formą:
- Kiekviena modifikacija atliekama atskiroje šakoje, kuri atitinka diegimo paketą ir susilieja į tikslinę pagrindinę šaką;
- Dujotiekio paleidimo aktyviklis yra naujo įsipareigojimo atsiradimas pagrindinėje šakoje per sujungimo užklausą, kurią uždaro vidinės komandos prižiūrėtojai;
- Saugyklos sinchronizuojamos kartą per penkias minutes;
- Diegimo paketo surinkimas pradedamas naudojant surinkėją, gautą iš pardavėjo.
Po to jau buvo atlikti kodo patikrinimo ir perdavimo žingsniai, vamzdžio paleidimas ir surinkimas mūsų pusėje.
Ši parinktis buvo pristatyta liepos mėnesį. Perėjimo sunkumai sukėlė tam tikrą pardavėjo ir fronto linijos nepasitenkinimą, tačiau per kitą mėnesį mums pavyko pašalinti visus grubus kraštus ir nustatyti procesą tarp komandų. Dabar turime surinkimą pagal įsipareigojimą ir pristatymą.
Rugpjūčio mėnesį mums pavyko užbaigti pirmąjį atskiro paketo diegimą gamyboje naudojant mūsų konvejerį, o nuo rugsėjo be išimties visi atskirų neišleidžiamų paketų diegimai buvo atlikti per mūsų CD įrankį. Be to, mums pavyko atlikti vidinių užduočių dalį 40% leidimo sudėties su mažesne komanda nei pardavėjas – tai neabejotina sėkmė. Liko rimčiausia užduotis – surinkti ir įdiegti laidą.
Galutinis sprendimas: kaupiamieji diegimo paketai
Puikiai supratome, kad pardavėjo instrukcijų scenarijų sudarymas buvo toks automatizavimas; turėjome permąstyti patį procesą. Sprendimas buvo akivaizdus – surinkti kaupiamą atsargą iš išleidimo šakos su visais reikiamų versijų objektais.
Pradėjome nuo koncepcijos įrodymo: rankomis surinkome leidimo paketą pagal ankstesnio diegimo turinį ir įdiegėme jį savo aplinkoje. Viskas pavyko, koncepcija pasirodė perspektyvi. Tada išsprendėme inicijavimo nustatymų scenarijų sudarymo ir įtraukimo į įsipareigojimą problemą. Mes paruošėme naują paketą ir išbandėme jį testavimo aplinkose kaip kontūro atnaujinimo dalį. Diegimas buvo sėkmingas, nors su daugybe komentarų iš diegimo komandos. Tačiau svarbiausia yra tai, kad mums buvo duotas leidimas pradėti gamybą lapkričio mėnesio leidime kartu su mūsų surinkimu.
Likus kiek daugiau nei mėnesiui, rankomis atrinktos prekės aiškiai rodė, kad laikas bėga. Jie nusprendė sukurti iš leidimo šakos, bet kodėl ji turėtų būti atskirta? Neturime Prod tipo, o esami filialai nėra geri – yra daug nereikalingo kodo. Turime skubiai sumažinti gaminius patinkančius žmones, o tai yra daugiau nei trys tūkstančiai įsipareigojimų. Rankiniu būdu surinkti nėra galimybės. Nubrėžėme scenarijų, kuris veikia produkto diegimo žurnale ir renka įsipareigojimus filialui. Trečią kartą veikė teisingai, o „užbaigus byla“ šaka buvo paruošta.
Parašėme savo statybininką montavimo paketui ir baigėme per savaitę. Tada turėjome modifikuoti diegimo programą iš pagrindinių sistemos funkcijų, nes ji yra atvirojo kodo. Po daugybės patikrinimų ir pakeitimų rezultatas buvo laikomas sėkmingu. Tuo tarpu susiformavo leidimo kompozicija, kurios teisingam įdiegimui reikėjo sulyginti bandomąją grandinę su gamybine, ir tam buvo parašytas atskiras scenarijus.
Natūralu, kad buvo daug komentarų apie pirmąjį diegimą, tačiau apskritai kodas veikė. Ir po maždaug trečio įdiegimo viskas pradėjo atrodyti gerai. Kompozicijos kontrolė ir objektų versijų kontrolė buvo stebima atskirai rankiniu režimu, kas šiame etape buvo gana pagrįsta.
Papildomas iššūkis buvo didelis neišleidimų skaičius, į kurį reikėjo atsižvelgti. Tačiau su Prod tipo šaka ir Rebase užduotis tapo skaidri.
Pirmą kartą, greitai ir be klaidų
Į leidimą žiūrėjome optimistiškai ir daugiau nei tuziną sėkmingų instaliacijų įvairiose grandinėse. Tačiau pažodžiui likus dienai iki termino paaiškėjo, kad pardavėjas nebaigė darbo, kad paruoštų leidimą diegimui priimtu būdu. Jei dėl kokių nors priežasčių mūsų versija neveikia, leidimas bus sutrikdytas. Be to, mūsų pastangomis, o tai ypač nemalonu. Neturėjome kaip trauktis. Todėl apgalvojome alternatyvius variantus, parengėme veiksmų planus ir pradėjome montuoti.
Keista, kad visas leidimas, susidedantis iš daugiau nei 800 objektų, pirmą kartą prasidėjo teisingai ir vos per 10 minučių. Praleidome valandą tikrindami žurnalus, ieškodami klaidų, bet jų neradome.
Visą kitą dieną išleidimo pokalbyje tvyrojo tyla: jokių diegimo problemų, kreivų versijų ar „netinkamo“ kodo. Netgi buvo kažkaip nejauku. Vėliau atsirado kai kurių pastabų, tačiau lyginant su kitomis sistemomis ir ankstesne patirtimi, jų skaičius ir prioritetas buvo pastebimai mažesni.
Papildomas kumuliacinio poveikio efektas buvo surinkimo ir testavimo kokybės pagerėjimas. Dėl daugybės viso leidimo diegimų laiku buvo nustatyti kūrimo defektai ir diegimo klaidos. Viso išleidimo konfigūracijų bandymai leido papildomai nustatyti objektų abipusės įtakos defektus, kurie neatsirado inkrementinio diegimo metu. Tai tikrai buvo sėkminga, ypač atsižvelgiant į mūsų 57% indėlį į leidimą.
Rezultatai ir išvados
Per mažiau nei metus mums pavyko:
- Sukurti visavertį vidinį vystymąsi naudojant egzotišką sistemą;
- Pašalinkite kritinę priklausomybę nuo pardavėjo;
- Paleiskite CI/CD, kad gautumėte labai nedraugišką palikimą;
- Pakelti įgyvendinimo procesus į naują techninį lygį;
- Žymiai sutrumpinkite diegimo laiką;
- Žymiai sumažinti įgyvendinimo klaidų skaičių;
- Užtikrintai paskelbkite save kaip pirmaujančią plėtros ekspertą.
Žinoma, daugelis to, kas aprašyta, atrodo kaip visiškas šūdas, tačiau tai yra sistemos ypatybės ir joje egzistuojantys proceso apribojimai. Šiuo metu pakeitimai palietė IS Profile produktus ir paslaugas (pagrindines sąskaitas, plastikines korteles, taupomąsias sąskaitas, sąlyginio deponavimo, grynųjų pinigų paskolas), tačiau potencialiai metodas gali būti pritaikytas bet kuriai IS, kuriai yra nustatyta DevOps praktikų diegimo užduotis. Kaupiamasis modelis gali būti saugiai atkartotas vėlesniems diegimams (įskaitant neišleistus) iš daugelio pristatymų.
Šaltinis: www.habr.com