DevOpsi praktikad töötavad. Selles veendusime ka ise, kui vähendasime väljalaske installimise aega 10 korda. Süsteemis FIS Profile, mida VTB-s kasutame, võtab installimine nüüd 90 asemel 10 minutit. Väljalaske koostamisaeg on vähenenud kahelt nädalalt kahele päevale. Püsivate juurutusvigade arv on langenud peaaegu miinimumini. Et “käsitööst” eemalduda ja müüjast sõltuvust kaotada, tuli töötada karkudega ja leida ootamatuid lahendusi. Lõike all on üksikasjalik lugu sellest, kuidas ehitasime üles täisväärtusliku sisearengu.
Proloog: DevOps on filosoofia
Viimase aasta jooksul oleme teinud palju tööd DevOps praktikate sisemise arendamise ja juurutamise korraldamiseks VTB-s:
- Ehitasime 12 süsteemi sisemised arendusprotsessid;
- Käivitasime 15 torujuhet, millest neli viidi tootmisse;
- Automatiseeritud 1445 katsestsenaariumit;
- Oleme edukalt juurutanud mitmeid ettevõttesiseste meeskondade koostatud väljalaseid.
Üheks kõige keerulisemaks korraldatavaks ettevõttesiseseks arenduseks ja DevSecOpsi praktikate juurutamiseks osutus FIS Profile süsteem – jaemüügi tooteprotsessor mitterelatsioonilisel DBMS-il. Sellegipoolest suutsime arendada, käivitada torujuhtme, installida tootele üksikud väljalaskevabad paketid ja õppisime väljalaseid kokku panema. Ülesanne polnud lihtne, kuid huvitav ja ilma ilmsete piiranguteta rakendamisel: siin on süsteem - peate ehitama majasisese arenduse. Ainus tingimus on kasutada CD-d enne produktiivset keskkonda.
Algul tundus rakendusalgoritm lihtne ja selge:
- Arendame välja esmased arendusteadmised ja saavutame koodimeeskonnalt vastuvõetava kvaliteeditaseme ilma suurte defektideta;
- Integreerime võimalikult palju olemasolevatesse protsessidesse;
- Koodi ülekandmiseks ilmsete etappide vahel lõikame torujuhtme ja lükkame selle ühe otsa jätkusse.
Selle aja jooksul peab vajaliku suurusega arendusmeeskond arendama oskusi ja suurendama oma panuse osakaalu väljalasetes vastuvõetavale tasemele. Ja ongi kõik, võime lugeda ülesande lõpetatuks.
Tundub, et see on täiesti energiasäästlik tee vajaliku tulemuseni: siin on DevOps, siin on meeskonna jõudlusnäitajad, siin on kogunenud asjatundlikkus... Kuid praktikas saime veel ühe kinnituse, et DevOps on ikkagi filosoofiaga. , mitte "seotud gitlabi protsessiga, ansible, nexus ja loendis allpool".
Olles veel kord tegevuskava analüüsinud, mõistsime, et ehitame enda sisse omamoodi allhankemüüjat. Seetõttu lisati ülalkirjeldatud algoritmile protsesside ümberkujundamine, samuti kogu arendustee vältel asjatundlikkuse arendamine, et saavutada selles protsessis juhtroll. Pole just kõige lihtsam variant, aga see on ideoloogiliselt õige arengu tee.
Kust algab sisearendus?
See ei olnud kõige sõbralikum süsteem, millega töötada. Arhitektuuriliselt oli see üks suur mitterelatsiooniline DBMS, mis koosnes paljudest eraldi käivitatavatest objektidest (skriptid, protseduurid, partiid jne), mida kutsuti vastavalt vajadusele ja töötas musta kasti põhimõttel: võtab päringu vastu ja väljastab. vastus. Muud tähelepanu väärivad raskused on järgmised:
- Eksootiline keel (MUMPS);
- konsooli liides;
- Integratsiooni puudumine populaarsete automatiseerimistööriistade ja -raamistikega;
- Andmemaht kümnetes terabaitides;
- Koormus üle 2 miljoni toimingu tunnis;
- Tähtsus – ärikriitiline.
Samal ajal ei olnud meie poolel lähtekoodi hoidlat. Üleüldse. Dokumentatsioon oli olemas, kuid kõik võtmeteadmised ja -pädevused olid välise organisatsiooni poolel.
Hakkasime süsteemi arendamist valdama peaaegu nullist, võttes arvesse selle funktsioone ja madalat levikut. Algas oktoobris 2018:
- Õppinud dokumentatsiooni ja koodi genereerimise aluseid;
- Uurisime müüjalt saadud arenduse lühikursust;
- Omandatud esmased arendusoskused;
- Koostasime uutele meeskonnaliikmetele koolitusjuhendi;
- Leppisime kokku, et kaasame meeskonna võitlusrežiimi;
- Lahendatud probleem koodi kvaliteedikontrolliga;
- Korraldasime arendusstendi.
Kolm kuud arendasime asjatundlikkust ja sukeldusime süsteemi ning 2019. aasta algusest alustas inhouse arendus vahel vaevaliselt, kuid enesekindlalt ja sihikindlalt liikumist helge tuleviku suunas.
Hoidla migreerimine ja automaattestid
Esimene DevOpsi ülesanne on hoidla. Leppisime kiiresti kokku juurdepääsu võimaldamises, kuid oli vaja migreerida praeguselt ühe magistraalharuga SVN-ilt meie sihtmärgi Gitile üleminekuga mitme haru mudelile ja Git Flow arendamisele. Meil on ka 2 meeskonda oma infrastruktuuriga, pluss osa müüja meeskonnast välismaal. Pidin elama kahe Gitiga ja tagama sünkroonimise. Sellises olukorras oli see kahest pahest väiksem.
Hoidla migratsiooni lükati korduvalt edasi, see valmis alles aprillis rindekolleegide abiga. Git Flow'ga otsustasime hoida asjad alustuseks lihtsad ja asusime käigultparandusega, arendama ja vabastama klassikalise skeemi juurde. Nad otsustasid meistrist (aka prod-like) hüljata. Allpool selgitame, miks see valik meie jaoks optimaalseks osutus. Töötajana kasutati müüjale kuuluvat välist hoidlat, mis on ühine kahe meeskonna jaoks. See sünkrooniti ajakava kohaselt sisemise hoidlaga. Nüüd oli Giti ja Gitlabiga võimalik protsesse automatiseerida.
Autotestide küsimus lahenes üllatavalt lihtsalt - meile anti valmis raamistik. Süsteemi iseärasusi arvestades oli eraldi toimingu kutsumine äriprotsessi arusaadav osa ja toimis samas ka üksusetestina. Jäi vaid ette valmistada testiandmed ning seada skriptide kutsumise ja tulemuste hindamise soovitud järjekord. Toimimisstatistika, protsesside kriitilisuse ja olemasoleva regressioonimetoodika põhjal koostatud stsenaariumide loetelu täitumisel hakkasid tekkima automaattestid. Nüüd võiksime alustada torujuhtme ehitamist.
Kuidas see oli: mudel enne automatiseerimist
Olemasolev rakendusprotsessi mudel on omaette lugu. Iga modifikatsioon kanti käsitsi üle eraldi järkjärgulise installipaketina. Edasi tuli käsitsi registreerimine Jiras ja käsitsi installimine keskkondadesse. Üksikpakettide puhul paistis kõik selge, kuid väljalaske ettevalmistamisega oli asi keerulisem.
Kokkupanek viidi läbi üksikute tarnete tasemel, mis olid iseseisvad objektid. Iga muudatus on uus tarne. Muuhulgas lisati põhiväljalaske koostise 60-70 paketti 10–15 tehnilist versiooni - versioonid, mis saadi väljalasele millegi lisamisel või väljajätmisel ning kajastavad müügimuutusi väljaspool väljalaseid.
Tarnete sees olevad objektid kattusid üksteisega, eriti käivitatavas koodis, mis oli vähem kui poole võrra unikaalne. Sõltuvusi oli palju nii juba installitud koodist kui ka sellest, mille installimine oli just plaanis.
Koodi vajaliku versiooni saamiseks oli vaja rangelt järgida paigaldusjärjekorda, mille käigus kirjutati objekte füüsiliselt ümber palju kordi, mõni 10–12 korda.
Pärast pakettide partii installimist pidin seadete lähtestamiseks käsitsi järgima juhiseid. Väljalaske pani kokku ja paigaldas müüja. Väljalaske koostis selgitati peaaegu enne juurutamise hetke, mis tõi kaasa pakettide lahtisidumise. Selle tulemusel liikus märkimisväärne osa tarnetest vabastamiselt vabastamiseni oma "lahtisidumise" sabaga.
Nüüd on selge, et sellise lähenemise puhul – väljalaskepusle kokkupanemine paketi tasemel – ei omanud ühel põhiharul praktilist tähendust. Tootmisse paigaldamine võttis poolteist kuni kaks tundi käsitsitööd. Hea, et vähemalt paigaldaja tasemel oli objektide töötlemise järjekord määratud: väljad ja struktuurid sisestati enne nende ja protseduuride andmeid. See toimis aga ainult eraldi paketis.
Selle lähenemise loogiliseks tulemuseks olid kohustuslikud paigaldusvead objektide kõverate versioonide, tarbetu koodi, puuduvate juhiste ja objektide vastastikuse mõjutamise näol, mis pärast vabastamist palavikuliselt kõrvaldati.
Esimesed uuendused: kokkupanek ja tarnimine
Automatiseerimine algas koodi edastamisega toru kaudu seda teed pidi:
- Võtke valmis saadetis laost ära;
- Installige see spetsiaalsesse keskkonda;
- Käivitage automaattestid;
- Hinda paigaldustulemust;
- Kutsuge testimiskäsu küljel järgmine konveier.
Järgmine konveier peaks ülesande Jiras registreerima ja ootama, kuni käsud jagatakse valitud testimistsüklitele, mis sõltuvad ülesande rakendamise ajastusest. Päästik - kiri valmisoleku kohta kohaletoimetamiseks etteantud aadressile. See oli muidugi ilmselge kark, kuid ma pidin kuskilt alustama. 2019. aasta mais algas koodi ülekandmine meie keskkondade kontrollimisega. Protsess on alanud, jääb vaid see korralikku vormi viia:
- Iga modifikatsioon tehakse eraldi harus, mis vastab installipaketile ja sulandub sihtrühma põhiharusse;
- Konveieri käivitamise päästikuks on uue kohustuse ilmumine põhiharus liitmistaotluse kaudu, mille sulgevad ettevõttesisese meeskonna hooldajad;
- Hoidlad sünkroonitakse üks kord iga viie minuti järel;
- Paigalduspaketi kokkupanemist alustatakse - kasutades müüjalt saadud komplekteerijat.
Pärast seda olid juba olemas sammud koodi kontrollimiseks ja ülekandmiseks, toru käivitamiseks ja kokkupanekuks meie poolel.
See valik võeti kasutusele juulis. Ülemineku raskused tõid kaasa mõningase rahulolematuse müüja ja eesliini seas, kuid järgmise kuu jooksul õnnestus meil eemaldada kõik ebatasasused ja luua meeskondade vahel protsess. Nüüd on meil komplekteerimine ja tarnimine.
Augustis õnnestus meil oma torujuhtme abil lõpetada tootmises eraldiseisva paketi esimene installimine ja alates septembrist teostati eranditult kõik üksikute mitteväljastavate pakettide installid meie CD-tööriista kaudu. Lisaks õnnestus meil müüjast väiksema meeskonnaga saavutada sisemiste ülesannete osakaal 40% väljalaske koostisest – see on kindel edu. Kõige tõsisem ülesanne jäi alles - väljalase kokkupanek ja installimine.
Lõplik lahendus: kumulatiivsed installipaketid
Saime suurepäraselt aru, et müüja juhiste skriptimine oli nii-nii automatiseerimine; pidime protsessi enda ümber mõtlema. Lahendus oli ilmne - koguda väljalaskeharust kumulatiivne varu koos kõigi vajalike versioonide objektidega.
Alustasime kontseptsiooni tõestamisega: koostasime väljalaskepaketi käsitsi vastavalt varasema juurutuse sisule ja installisime selle oma keskkondadesse. Kõik õnnestus, kontseptsioon osutus elujõuliseks. Järgmisena lahendasime initsialiseerimisseadete skriptimise ja nende lisamise probleemi. Koostasime uue paketi ja testisime seda kontuuriuuenduse raames testimiskeskkondades. Installimine õnnestus, kuigi juurutusmeeskonnalt oli palju kommentaare. Kuid peamine on see, et meile anti luba alustada tootmist novembris koos oma komplektiga.
Kuna aega oli jäänud veidi üle kuu, andsid käsitsi valitud varud selgelt mõista, et aeg hakkab otsa saama. Nad otsustasid ehitada väljalaskeharust, kuid miks peaks see eraldama? Meil ei ole Prod-tüüpi ja olemasolevad filiaalid pole head – seal on palju tarbetut koodi. Peame kiiresti kärpima toote-meeldivaid kasutajaid ja see on üle kolme tuhande kohustuse. Käsitsi kokkupanek pole üldse võimalik. Visandasime skripti, mis jookseb läbi toote installilogi ja kogub harule kohustusi. Kolmandal korral töötas korralikult ja peale “viiliga viimistlemist” oli oks valmis.
Paigalduspaketile kirjutasime oma ehitaja ja valmis nädalaga. Seejärel pidime installijat muutma süsteemi põhifunktsioonidest, kuna see on avatud lähtekoodiga. Pärast mitmeid kontrolle ja muudatusi loeti tulemus edukaks. Vahepeal kujunes välja väljalaske koosseis, mille õigeks paigaldamiseks oli vaja testahela tootmisahelaga joondada ja selle jaoks kirjutati eraldi skript.
Loomulikult oli esimese installi kohta palju kommentaare, kuid üldiselt kood töötas. Ja umbes pärast kolmandat installimist hakkas kõik hea välja nägema. Käsirežiimis jälgiti eraldi objektide koosseisukontrolli ja versioonikontrolli, mis antud etapis oli igati õigustatud.
Täiendavaks väljakutseks oli mitteväljaannete suur hulk, millega tuli arvestada. Kuid Prod-laadse haru ja Rebase abil muutus ülesanne läbipaistvaks.
Esimest korda, kiiresti ja ilma vigadeta
Suhtusime väljalasele optimistliku suhtumisega ja enam kui tosina õnnestunud installatsiooniga erinevatel vooluringidel. Kuid sõna otseses mõttes päev enne tähtaega selgus, et müüja ei olnud lõpetanud tööd versiooni ettevalmistamiseks installimiseks aktsepteeritud viisil. Kui meie ehitus mingil põhjusel ei tööta, katkestatakse väljalase. Veelgi enam, meie pingutuste kaudu, mis on eriti ebameeldiv. Meil polnud võimalust taganeda. Seetõttu mõtlesime läbi alternatiivsed võimalused, koostasime tegevuskavad ja alustasime paigaldamist.
Üllataval kombel algas kogu enam kui 800 objektist koosnev väljalase õigesti, esimest korda ja kõigest 10 minutiga. Veetsime tund aega logide kontrollimisel vigu otsides, kuid ei leidnud ühtegi.
Terve järgmise päeva valitses väljalaskevestluses vaikus: juurutusprobleeme, kõveraid versioone ega "sobimatut" koodi ei olnud. See oli isegi kuidagi ebamugav. Hiljem tekkisid mõned kommentaarid, kuid võrreldes teiste süsteemide ja varasema kogemusega oli nende arv ja prioriteetsus märgatavalt väiksem.
Kumulatiivsest mõjust tulenev lisaefekt oli kokkupaneku ja katsetamise kvaliteedi tõus. Täieliku versiooni mitme installimise tõttu tuvastati õigeaegselt ehitusdefektid ja juurutusvead. Täieliku vabastamise konfiguratsioonide testimine võimaldas täiendavalt tuvastada objektide vastastikuse mõju defekte, mis ei ilmnenud järkjärgulise installimise ajal. See oli kindlasti edukas, eriti arvestades meie 57% panust väljalaskesse.
Kokkuvõte ja järeldused
Vähem kui aastaga õnnestus meil:
- Looge eksootilise süsteemi abil täisväärtuslik sisemine areng;
- Likvideerida kriitiline sõltuvus hankijast;
- Käivitage CI/CD väga ebasõbraliku pärandi jaoks;
- Tõsta rakendusprotsessid uuele tehnilisele tasemele;
- Vähendage oluliselt juurutamisaega;
- Vähendage oluliselt rakendusvigade arvu;
- Tunnista end enesekindlalt juhtivaks arenduseksperdiks.
Muidugi näeb suur osa kirjeldatust välja otsene jama, kuid need on süsteemi omadused ja selles esinevad protsessipiirangud. Hetkel puudutasid muudatused IS Profile'i tooteid ja teenuseid (põhikontod, plastikkaardid, kogumiskontod, tingdeponeerimine, sularahalaenud), kuid potentsiaalselt saab lähenemist rakendada igale IS-ile, millele on seatud ülesandeks DevOps praktikate juurutamine. Kumulatiivset mudelit saab ohutult replitseerida paljude tarnete järgnevate juurutuste jaoks (kaasa arvatud väljalaskmata).
Allikas: www.habr.com