DevOps æfingar virka. Við vorum sjálf sannfærð um þetta þegar við styttum uppsetningartíma útgáfunnar um 10 sinnum. Í FIS Profile kerfinu, sem við notum hjá VTB, tekur uppsetningin núna 90 mínútur frekar en 10. Útgáfutíminn hefur minnkað úr tveimur vikum í tvo daga. Fjöldi viðvarandi útfærslugalla hefur farið niður í nánast lágmark. Til að komast burt frá „handavinnu“ og koma í veg fyrir háð seljanda þurftum við að vinna með hækjur og finna óvæntar lausnir. Fyrir neðan klippuna er ítarleg saga um hvernig við byggðum upp fullgilda innri þróun.
Formáli: DevOps er heimspeki
Undanfarið ár höfum við lagt mikla vinnu í að skipuleggja innri þróun og innleiðingu á DevOps starfsháttum hjá VTB:
- Við smíðuðum innri þróunarferli fyrir 12 kerfi;
- Við hleyptum af stokkunum 15 leiðslum, þar af voru fjórar teknar í framleiðslu;
- Sjálfvirk 1445 próf atburðarás;
- Okkur tókst að innleiða fjölda útgáfur sem unnar voru af teymum innanhúss.
Eitt það erfiðasta við að skipuleggja þróun innanhúss og innleiðingu á DevSecOps starfsháttum reyndist vera FIS Profile kerfið - smásöluvöruvinnsla á DBMS sem ekki tengist. Engu að síður gátum við byggt upp þróunina, ræst leiðsluna, sett upp einstaka pakka sem ekki voru gefnar út á vörunni og lært hvernig á að setja saman útgáfur. Verkefnið var ekki auðvelt, en áhugavert og án augljósra takmarkana í framkvæmd: hér er kerfið - þú þarft að byggja upp þróun innanhúss. Eina skilyrðið er að nota geisladiskinn fyrir afkastamikið umhverfi.
Í fyrstu virtist útfærslualgrímið einfalt og skýrt:
- Við þróum sérfræðiþekkingu á frumþróun og náum viðunandi gæðastigi frá kóðateyminu án stórfelldra galla;
- Við samþættum núverandi ferla eins mikið og mögulegt er;
- Til að flytja kóða á milli augljósra þrepa, skerum við leiðslu og ýtum einum enda hennar inn í framhaldið.
Á þessum tíma verður þróunarteymið af tilskildri stærð að þróa færni og auka hlut framlags síns til útgáfur í ásættanlegt stig. Og það er það, við getum talið verkefninu lokið.
Svo virðist sem þetta sé algjörlega orkusparandi leið að tilskildri niðurstöðu: hér er DevOps, hér eru árangursmælingar liðsins, hér er uppsöfnuð sérfræðiþekking... En í reynd fengum við aðra staðfestingu á því að DevOps snýst enn um heimspeki , og ekki "tengt gitlab ferlinu, ansible, nexus og neðar á listanum."
Eftir að hafa greint aðgerðaáætlunina enn og aftur komumst við að því að við vorum að byggja upp eins konar útvistunarsöluaðila innra með okkur. Þess vegna var endurgerð ferli bætt við reikniritið sem lýst er hér að ofan, sem og þróun sérfræðiþekkingar á allri þróunarleiðinni til að ná leiðandi hlutverki í þessu ferli. Ekki auðveldasti kosturinn, en þetta er leið hugmyndafræðilega réttrar þróunar.
Hvar hefst þróun innanhúss?
Þetta var ekki vinalegasta kerfið til að vinna með. Byggingarfræðilega séð var þetta eitt stórt DBMS sem ekki tengist skyldleika, samanstóð af mörgum aðskildum keyranlegum hlutum (forskriftir, verklagsreglur, runur o.s.frv.), sem kallaðir voru eftir þörfum, og starfaði á meginreglunni um svartan kassa: það tekur við beiðni og gefur út svar. Aðrir erfiðleikar sem vert er að taka eftir eru:
- Framandi tungumál (MUMPS);
- Console tengi;
- Skortur á samþættingu við vinsæl sjálfvirkniverkfæri og ramma;
- Gagnamagn í tugum terabæta;
- Álag yfir 2 milljónir aðgerða á klukkustund;
- Mikilvægi - Viðskiptagagnrýnið.
Á sama tíma var engin frumkóðageymsla hjá okkur. Alls. Það var skjöl, en öll lykilþekking og hæfni var á hlið utanaðkomandi stofnunar.
Við byrjuðum að ná tökum á þróun kerfisins nánast frá grunni, að teknu tilliti til eiginleika þess og lítillar dreifingar. Byrjað í október 2018:
- Lærði skjöl og grunnatriði kóðagerðar;
- Við lærðum stutta námskeiðið um þróun sem fékkst frá seljanda;
- Náði tökum á fyrstu þroskafærni;
- Við tókum saman þjálfunarhandbók fyrir nýja liðsmenn;
- Við samþykktum að hafa liðið í „bardaga“ ham;
- Leysti málið með gæðaeftirliti með kóða;
- Við skipulögðum þróunarstand.
Við eyddum þremur mánuðum í að þróa sérfræðiþekkingu og sökkva okkur inn í kerfið og frá ársbyrjun 2019 hófst þróun innanhúss í átt að bjartri framtíð, stundum með erfiðleikum, en af öryggi og markvisst.
Flutningur geymslu og sjálfvirkar prófanir
Fyrsta DevOps verkefnið er geymslan. Við komumst fljótt að samkomulagi um að veita aðgang, en það var nauðsynlegt að flytja úr núverandi SVN með einni stofnútibúi yfir í miða Git með umskipti yfir í líkan af nokkrum greinum og þróun Git Flow. Við erum líka með 2 teymi með eigin innviði, auk hluta af teymi seljanda erlendis. Ég þurfti að lifa með tveimur Gits og tryggja samstillingu. Í slíkum aðstæðum var það minna af tvennu illu.
Flutningi geymslunnar var ítrekað frestað, því var aðeins lokið í apríl, með aðstoð samstarfsmanna úr fremstu víglínu. Með Git Flow ákváðum við að hafa hlutina einfalda til að byrja með og sættum okkur við hið klassíska kerfi með flýtileiðréttingu, þróun og útgáfu. Þeir ákváðu að yfirgefa meistara (aka prod-like). Hér að neðan munum við útskýra hvers vegna þessi valkostur reyndist vera ákjósanlegur fyrir okkur. Ytri geymsla sem tilheyrir seljanda, sameiginleg fyrir tvö teymi, var notuð sem starfsmaður. Það var samstillt við innri geymsluna samkvæmt áætlun. Nú með Git og Gitlab var hægt að gera sjálfvirkan ferla.
Vandamálið um sjálfvirkar prófanir leystist furðu auðveldlega - okkur var útvegað tilbúið ramma. Að teknu tilliti til sérkenna kerfisins var það skiljanlegur hluti af viðskiptaferlinu að kalla á sérstaka aðgerð og um leið sem einingapróf. Það eina sem var eftir var að undirbúa prófunargögnin og stilla æskilega röð til að hringja í forskriftirnar og meta niðurstöðurnar. Þegar listi yfir sviðsmyndir, sem myndaður var á grundvelli rekstrartölfræði, mikilvægi ferla og núverandi aðhvarfsaðferðafræði, fylltist út, fóru sjálfvirk próf að birtast. Nú gætum við byrjað að byggja leiðsluna.
Hvernig það var: líkanið fyrir sjálfvirkni
Fyrirliggjandi líkan af innleiðingarferlinu er sérstök saga. Hver breyting var handvirkt flutt sem sérstakur stigvaxandi uppsetningarpakki. Næst kom handvirk skráning í Jira og handvirk uppsetning á umhverfi. Fyrir einstaka pakka leit allt út fyrir að vera skýrt, en með undirbúningi útgáfunnar voru hlutirnir flóknari.
Samsetning fór fram á stigi einstakra afhendinga, sem voru sjálfstæðir hlutir. Allar breytingar eru ný sending. Meðal annars var 60–70 tæknilegum útgáfum bætt við 10-15 pakka aðalútgáfusamsetningarinnar - útgáfur sem fengust þegar eitthvað var bætt við eða útilokað frá útgáfunni og endurspegla breytingar á sölu utan útgáfunnar.
Hlutir innan afhendinganna skarast hver við annan, sérstaklega í keyrslukóðanum, sem var minna en hálf einstakt. Það voru mörg ósjálfstæði bæði á kóðanum sem þegar var uppsettur og þeim sem uppsetningin var nýlega skipulögð.
Til að fá nauðsynlega útgáfu kóðans var nauðsynlegt að fylgja nákvæmlega uppsetningarröðinni, þar sem hlutir voru líkamlega endurskrifaðir oft, um 10–12 sinnum.
Eftir að hafa sett upp slatta af pakka þurfti ég að fylgja leiðbeiningunum handvirkt til að frumstilla stillingarnar. Útgáfan var sett saman og sett upp af seljanda. Samsetning útgáfunnar var skýrð næstum fyrir innleiðingu, sem fól í sér stofnun „aftengingar“ pakka. Fyrir vikið færðist umtalsverður hluti af birgðum frá útgáfu til losunar með eigin hala af „aftengingum“.
Nú er ljóst að með þessari nálgun - að setja saman útgáfupúslið á pakkastigi - hafði ein meistaragrein enga hagnýta merkingu. Uppsetning á framleiðslu tók allt frá eina og hálfa til tvær klukkustundir af handavinnu. Það er gott að að minnsta kosti á uppsetningarstigi var röð hlutavinnslu tilgreind: reitir og mannvirki voru færð inn á undan gögnum fyrir þá og verklagsreglur. Hins vegar virkaði þetta aðeins í sérstökum pakka.
Rökrétt niðurstaða þessarar nálgunar var skyldubundnir uppsetningargalla í formi skakka útgáfur af hlutum, óþarfa kóða, leiðbeininga sem vantaði og ógreinanleg gagnkvæm áhrif hluta, sem var útrýmt með hita eftir útgáfu.
Fyrstu uppfærslur: skuldbinda samsetningu og afhendingu
Sjálfvirkni hófst með því að senda kóða í gegnum pípu á þessari leið:
- Sæktu fullunna afhendingu úr geymslu;
- Settu það upp í sérstöku umhverfi;
- Keyra sjálfvirkar prófanir;
- Meta niðurstöðu uppsetningar;
- Hringdu í eftirfarandi leiðslu við hlið prófunarskipunarinnar.
Næsta leiðsla ætti að skrá verkefnið í Jira og bíða eftir að skipunum sé dreift í valdar prófunarlykkjur, sem eru háðar tímasetningu verkefnaútfærslunnar. Kveikja - bréf um reiðubúin til afhendingar á tiltekið heimilisfang. Þetta var auðvitað augljós hækja, en einhvers staðar varð ég að byrja. Í maí 2019 hófst flutningur kóða með eftirliti á umhverfi okkar. Ferlið er hafið, allt sem er eftir er að koma því í almennilegt form:
- Hver breyting er framkvæmd í sérstakri grein, sem samsvarar uppsetningarpakkanum og rennur saman í markmeistaraútibúið;
- Kveikja á leiðsluræsingu er útlit nýrrar skuldbindingar í aðalútibúinu í gegnum samrunabeiðni, sem er lokað af viðhaldsaðilum innanhússteymis;
- Geymslur eru samstilltar einu sinni á fimm mínútna fresti;
- Samsetning uppsetningarpakkans er hafin - með því að nota assembler sem fékkst frá seljanda.
Eftir þetta voru þegar fyrirliggjandi skref til að athuga og flytja kóðann, til að ræsa pípuna og setja saman á hlið okkar.
Þessi valkostur var opnaður í júlí. Erfiðleikarnir við umskiptin leiddu til nokkurrar óánægju meðal seljanda og framlínu, en á næsta mánuði tókst okkur að fjarlægja allar grófu brúnirnar og koma á ferli meðal teymanna. Við höfum nú samsetningu með skuldbindingu og afhendingu.
Í ágúst tókst okkur að klára fyrstu uppsetningu á sérstökum pakka við framleiðslu með því að nota leiðsluna okkar og síðan í september, undantekningarlaust, voru allar uppsetningar einstakra pakka sem ekki voru gefnar út í gegnum geisladiskatólið okkar. Að auki tókst okkur að ná hlutdeild í verkefnum innanhúss í 40% af útgáfusamsetningunni með minna teymi en seljandann - þetta er ákveðinn árangur. Alvarlegasta verkefnið var eftir - að setja saman og setja upp útgáfuna.
Lokalausnin: uppsafnaðar uppsetningarpakkar
Við skildum vel að það að skrifa leiðbeiningar seljanda var svo sem sjálfvirkni; við urðum að endurskoða ferlið sjálft. Lausnin var augljós - að safna uppsafnaðu framboði frá útgáfugreininni með öllum hlutum nauðsynlegra útgáfur.
Við byrjuðum með sönnun á hugmynd: við settum útgáfupakkann saman í höndunum í samræmi við innihald fyrri útfærslu og settum hann upp á umhverfi okkar. Allt gekk upp, hugmyndin reyndist raunhæf. Næst leystum við málið með að forskrifta frumstillingarstillingar og taka þær með í skuldbindingunni. Við útbjuggum nýjan pakka og prófuðum hann í prófunarumhverfi sem hluti af útlínuuppfærslunni. Uppsetningin tókst vel, að vísu með margvíslegum athugasemdum frá framkvæmdateyminu. En aðalatriðið er að við fengum leyfi til að fara í framleiðslu í nóvemberútgáfunni með samsetningunni okkar.
Þegar rúmur mánuður var eftir gáfu handvalnu birgðirnar greinilega í skyn að tíminn væri að renna út. Þeir ákváðu að gera bygginguna frá útgáfugreininni, en hvers vegna ætti það að vera aðskilið? Við erum ekki með Prod-líkan og núverandi útibú eru ekki góð - það er mikið af óþarfa kóða. Við þurfum brýn að skera niður prod-likes og þetta eru yfir þrjú þúsund skuldbindingar. Samsetning í höndunum er alls ekki valkostur. Við teiknuðum upp handrit sem liggur í gegnum uppsetningarskrá vörunnar og safnar skuldbindingum til útibúsins. Í þriðja skiptið virkaði það rétt og eftir að hafa „klárað með skrá“ var útibúið tilbúið.
Við skrifuðum okkar eigin smið fyrir uppsetningarpakkann og kláruðum hann á viku. Síðan þurftum við að breyta uppsetningarforritinu frá kjarnavirkni kerfisins, þar sem það er opinn uppspretta. Eftir nokkrar athuganir og breytingar þótti niðurstaðan farsæl. Í millitíðinni tók samsetning útgáfunnar á sig mynd, til að rétta uppsetningu hennar var nauðsynlegt að samræma prófunarrásina við framleiðsluna og sérstakt handrit var skrifað fyrir þetta.
Auðvitað voru margar athugasemdir um fyrstu uppsetninguna, en í heildina virkaði kóðinn. Og eftir um þriðju uppsetninguna fór allt að líta vel út. Samsetningarstýring og útgáfustýring á hlutum var fylgst sérstaklega með í handvirkri stillingu, sem á þessu stigi var alveg réttlætanlegt.
Önnur áskorun var sá mikli fjöldi óútgáfu sem þurfti að taka tillit til. En með Prod-eins greininni og Rebase varð verkefnið gagnsætt.
Í fyrsta skipti, fljótt og án villna
Við nálguðumst útgáfuna með bjartsýni viðhorf og meira en tug vel heppnaðra uppsetninga á mismunandi hringrásum. En bókstaflega degi fyrir frestinn kom í ljós að seljandinn hafði ekki lokið vinnu við að undirbúa útgáfuna fyrir uppsetningu á viðurkenndan hátt. Ef smíði okkar virkar ekki af einhverjum ástæðum truflast útgáfuna. Þar að auki, í gegnum viðleitni okkar, sem er sérstaklega óþægilegt. Við höfðum enga leið til að hörfa. Þess vegna hugsuðum við um aðra kosti, gerðum aðgerðaáætlanir og hófum uppsetningu.
Það kom á óvart að öll útgáfan, sem samanstendur af meira en 800 hlutum, byrjaði rétt, í fyrsta skipti og á aðeins 10 mínútum. Við eyddum klukkutíma í að skoða skrárnar í leit að villum, en fundum engar.
Allan daginn eftir var þögn í útgáfuspjallinu: engin útfærsluvandamál, skakkar útgáfur eða „óviðeigandi“ kóða. Það var meira að segja einhvern veginn óþægilegt. Síðar komu nokkrar athugasemdir fram en miðað við önnur kerfi og fyrri reynslu var fjöldi þeirra og forgangur áberandi lægri.
Viðbótaráhrif frá uppsöfnuðum áhrifum voru aukning á gæðum samsetningar og prófunar. Vegna margra uppsetningar á heildarútgáfunni, komu byggingargalla og uppsetningarvillur í ljós tímanlega. Prófanir í fullri útgáfustillingum gerðu það mögulegt að greina auk þess galla í gagnkvæmum áhrifum hluta sem komu ekki fram við stigvaxandi uppsetningar. Það heppnaðist svo sannarlega, sérstaklega í ljósi 57% framlags okkar til útgáfunnar.
Niðurstöður og niðurstöður
Á innan við ári tókst okkur að:
- Byggja upp fullgilda innri þróun með því að nota framandi kerfi;
- Útrýma mikilvægum söluaðila háð;
- Ræstu CI/CD fyrir mjög óvingjarnlegan arfleifð;
- Hækka innleiðingarferla á nýtt tæknilegt stig;
- Draga verulega úr dreifingartíma;
- Draga verulega úr fjölda innleiðingarvillna;
- Lýstu sjálfum þér af öryggi sem leiðandi þróunarsérfræðingi.
Auðvitað lítur margt af því sem lýst er út eins og algjört rugl, en þetta eru eiginleikar kerfisins og ferlitakmarkanir sem eru í því. Í augnablikinu höfðu breytingarnar áhrif á IS Profile vörur og þjónustu (aðalreikninga, plastkort, sparireikninga, escrow, reiðufé lán), en hugsanlega er hægt að beita nálguninni á hvaða upplýsingaþjónustu sem er sem verkefnið að innleiða DevOps starfshætti er sett fyrir. Hægt er að endurtaka uppsafnaða líkanið á öruggan hátt fyrir síðari útfærslur (þar á meðal þær sem ekki eru gefnar út) frá mörgum afhendingum.
Heimild: www.habr.com