Kā izveidot pilnvērtÄ«gu iekŔēju izstrādi, izmantojot DevOps ā€” VTB pieredzi

DevOps prakse darbojas. Mēs paÅ”i par to pārliecinājāmies, kad samazinājām izlaiduma instalÄ“Å”anas laiku 10 reizes. Sistēmā FIS Profile, ko izmantojam VTB, instalÄ“Å”ana tagad aizņem 90 minÅ«tes, nevis 10. IzlaiÅ”anas izveides laiks ir samazinājies no divām nedēļām lÄ«dz divām dienām. PastāvÄ«go ievieÅ”anas defektu skaits ir samazinājies gandrÄ«z lÄ«dz minimumam. Lai atbrÄ«votos no ā€œroku darbaā€ un likvidētu atkarÄ«bu no pārdevēja, mums bija jāstrādā ar kruÄ·iem un jāatrod negaidÄ«ti risinājumi. Zem griezuma ir detalizēts stāsts par to, kā mēs veidojām pilnvērtÄ«gu iekŔējo attÄ«stÄ«bu.

Kā izveidot pilnvērtÄ«gu iekŔēju izstrādi, izmantojot DevOps ā€” VTB pieredzi
 

Prologs: DevOps ir filozofija

Pēdējā gada laikā esam paveikuÅ”i lielu darbu, lai organizētu DevOps prakÅ”u iekŔējo izstrādi un ievieÅ”anu VTB:

  • Mēs izveidojām iekŔējos izstrādes procesus 12 sistēmām;
  • Mēs uzsākām 15 cauruļvadus, no kuriem četri tika nodoti ražoÅ”anai;
  • Automatizēti 1445 testa scenāriji;
  • Mēs veiksmÄ«gi ieviesām vairākus laidienus, ko sagatavojuÅ”as iekŔējās komandas.

Viena no visgrÅ«tāk organizējamām DevSecOps prakses iekŔējai izstrādei un ievieÅ”anai izrādÄ«jās FIS Profile sistēma - mazumtirdzniecÄ«bas produktu procesors uz nerelācijas DBVS. Neskatoties uz to, mēs varējām izveidot izstrādi, palaist konveijeru, produktā instalēt atseviŔķas paketes, kas nav izlaistas, un uzzinājām, kā salikt laidienus. Uzdevums nebija viegls, bet interesants un bez acÄ«mredzamiem ievieÅ”anas ierobežojumiem: lÅ«k, sistēma - jums ir jāveido iekŔēja izstrāde. VienÄ«gais nosacÄ«jums ir izmantot kompaktdisku pirms produktÄ«vas vides.

Sākumā ievieŔanas algoritms Ŕķita vienkārŔs un skaidrs:

  • Mēs attÄ«stām sākotnējās izstrādes zināŔanas un sasniedzam pieņemamu kvalitātes lÄ«meni no koda komandas bez rupjiem defektiem;
  • Iespēju robežās integrējamies esoÅ”ajos procesos;
  • Lai pārsÅ«tÄ«tu kodu starp acÄ«mredzamiem posmiem, mēs nogriežam cauruļvadu un vienu no tā galiem iespiežam turpinājumā.

Šajā laikā vajadzīgā lieluma izstrādes komandai ir jāattīsta prasmes un jāpalielina sava ieguldījuma daļa laidienos līdz pieņemamam līmenim. Un tas arī viss, mēs varam uzskatīt, ka uzdevums ir pabeigts.

Å Ä·iet, ka tas ir pilnÄ«gi energoefektÄ«vs ceļŔ lÄ«dz vajadzÄ«gajam rezultātam: Å”eit ir DevOps, Å”eit ir komandas veiktspējas rādÄ«tāji, Å”eit ir uzkrātā pieredze... Bet praksē mēs saņēmām kārtējo apstiprinājumu, ka DevOps joprojām ir filozofija. , nevis ā€œpiesaistÄ«ts Gitlab procesam, ansible, nexus un tālāk sarakstāā€.

Kārtējo reizi analizējot rÄ«cÄ«bas plānu, sapratām, ka sevÄ« veidojam sava veida ārpakalpojumu pārdevēju. Tāpēc iepriekÅ” aprakstÄ«tajam algoritmam tika pievienota procesa pārplānoÅ”ana, kā arÄ« ekspertÄ«zes attÄ«stÄ«Å”ana visā izstrādes marÅ”rutā, lai sasniegtu vadoÅ”o lomu Å”ajā procesā. Nav vieglākais variants, bet tas ir ideoloÄ£iski pareizas attÄ«stÄ«bas ceļŔ.
 

Kur sākas iekŔējā attÄ«stÄ«ba? 

Tā nebija tā draudzÄ«gākā sistēma, ar kuru strādāt. Arhitektoniski tā bija viena liela nerelāciju DBVS, sastāvēja no daudziem atseviŔķiem izpildāmiem objektiem (skripti, procedÅ«ras, paketes u.c.), kas tika izsaukti pēc vajadzÄ«bas, un darbojās pēc melnās kastes principa: saņem pieprasÄ«jumu un izdod atbilde. Citas grÅ«tÄ«bas, kas ir vērts atzÄ«mēt, ir Ŕādas:

  • Eksotiskā valoda (MUMPS);
  • konsoles interfeiss;
  • Integrācijas trÅ«kums ar populāriem automatizācijas rÄ«kiem un ietvariem;
  • Datu apjoms desmitos terabaitu;
  • Slodze vairāk nekā 2 miljonu operāciju stundā;
  • NozÄ«me ā€“ biznesam kritiska.

Tajā paŔā laikā mÅ«su pusē nebija pirmkoda repozitorija. Pavisam. Bija dokumentācija, bet visas galvenās zināŔanas un kompetences bija ārējās organizācijas pusē.
Sistēmas izstrādi sākām apgÅ«t gandrÄ«z no nulles, ņemot vērā tās Ä«paŔības un zemo izplatÄ«bu. Sākās 2018. gada oktobrÄ«:

  • Studējis dokumentāciju un kodu Ä£enerÄ“Å”anas pamatus;
  • Mēs izpētÄ«jām no pārdevēja saņemto Ä«so kursu par attÄ«stÄ«bu;
  • ApgÅ«tas sākotnējās attÄ«stÄ«bas prasmes;
  • Mēs sastādÄ«jām apmācÄ«bu rokasgrāmatu jaunajiem komandas dalÄ«bniekiem;
  • Vienojāmies iekļaut komandu ā€œkaujasā€ režīmā;
  • Atrisināja problēmu ar koda kvalitātes kontroli;
  • Mēs organizējām stendu attÄ«stÄ«bai.

Mēs pavadÄ«jām trÄ«s mēneÅ”us, attÄ«stot zināŔanas un iedziļinoties sistēmā, un no 2019. gada sākuma iekŔējā attÄ«stÄ«ba sāka savu virzÄ«bu uz gaiÅ”u nākotni, dažreiz ar grÅ«tÄ«bām, bet pārliecinoÅ”i un mērÄ·tiecÄ«gi.

Repozitorija migrācija un automātiskās pārbaudes

Pirmais DevOps uzdevums ir repozitorijs. Mēs ātri vienojāmies par piekļuves nodroÅ”ināŔanu, taču bija nepiecieÅ”ams migrēt no paÅ”reizējā SVN ar vienu maÄ£istrālo atzaru uz mÅ«su mērÄ·a Git, pārejot uz vairāku atzaru modeli un Git Flow attÄ«stÄ«bu. Mums ir arÄ« 2 komandas ar savu infrastruktÅ«ru, kā arÄ« daļa no pārdevēja komandas ārzemēs. Man bija jāsadzÄ«vo ar diviem Gits un jānodroÅ”ina sinhronizācija. Šādā situācijā tas bija mazākais no diviem ļaunumiem.

Krātuves migrācija tika vairākkārt atlikta, tā tika pabeigta tikai aprÄ«lÄ«, palÄ«dzot kolēģiem no frontes lÄ«nijas. Izmantojot Git Flow, mēs nolēmām, ka iesākumam viss ir vienkārÅ”s, un izvēlējāmies klasisko shēmu ar labojumfailu, izstrādājam un izlaidām. Viņi nolēma pamest meistaru (aka prod-like). Tālāk mēs paskaidrosim, kāpēc Ŕī opcija mums izrādÄ«jās optimāla. Kā darbinieks tika izmantots ārējais pārdevējam piederoÅ”s repozitorijs, kas ir kopÄ«gs divām komandām. Tas tika sinhronizēts ar iekŔējo repozitoriju saskaņā ar grafiku. Tagad ar Git un Gitlab bija iespējams automatizēt procesus.

Autotestu jautājums tika atrisināts pārsteidzoÅ”i viegli - mums tika nodroÅ”ināts gatavs karkass. Ņemot vērā sistēmas Ä«patnÄ«bas, atseviŔķas darbÄ«bas izsaukÅ”ana bija saprotama biznesa procesa sastāvdaļa un vienlaikus kalpoja arÄ« kā vienÄ«bas tests. Atlika tikai sagatavot testa datus un iestatÄ«t vēlamo skriptu izsaukÅ”anas un rezultātu izvērtÄ“Å”anas secÄ«bu. Aizpildoties scenāriju sarakstam, kas veidots, pamatojoties uz darbÄ«bas statistiku, procesu kritiskumu un esoÅ”o regresijas metodiku, sāka parādÄ«ties automātiskās pārbaudes. Tagad mēs varētu sākt bÅ«vēt cauruļvadu.

Kā tas bija: modelis pirms automatizācijas

EsoÅ”ais ievieÅ”anas procesa modelis ir atseviŔķs stāsts. Katra modifikācija tika manuāli pārsÅ«tÄ«ta kā atseviŔķa inkrementālās instalācijas pakotne. Tālāk sekoja manuāla reÄ£istrācija Jira un manuāla instalÄ“Å”ana vidēs. AttiecÄ«bā uz atseviŔķiem iepakojumiem viss izskatÄ«jās skaidrs, bet ar laidiena sagatavoÅ”anu viss bija sarežģītāk.

Montāža tika veikta atseviŔķu piegāžu lÄ«menÄ«, kas bija neatkarÄ«gi objekti. Jebkuras izmaiņas ir jauna piegāde. Cita starpā galvenā laidiena sastāva 60ā€“70 pakotnēm tika pievienotas 10ā€“15 tehniskās versijas - versijas, kas iegÅ«tas, kaut ko pievienojot vai izslēdzot no laidiena un atspoguļojot pārdoÅ”anas izmaiņas ārpus laidieniem.

Piegāžu objekti pārklājās viens ar otru, jo Ä«paÅ”i izpildāmajā kodā, kas bija mazāk nekā puse unikāls. Bija daudz atkarÄ«bu gan no jau instalētā koda, gan no tā, kura instalÄ“Å”ana tikko bija plānota. 

Lai iegÅ«tu nepiecieÅ”amo koda versiju, bija stingri jāievēro uzstādÄ«Å”anas secÄ«ba, kuras laikā objekti tika fiziski pārrakstÄ«ti daudzas reizes, kādas 10ā€“12 reizes.

Pēc pakotņu partijas instalÄ“Å”anas man bija manuāli jāizpilda norādÄ«jumi, lai inicializētu iestatÄ«jumus. Izlaidumu montēja un uzstādÄ«ja pārdevējs. Izlaiduma sastāvs tika noskaidrots gandrÄ«z pirms ievieÅ”anas brīža, kas ietvēra "atsaistes" pakotņu izveidi. Rezultātā ievērojama daļa piegāžu pārvietojās no izlaiÅ”anas uz izlaiÅ”anu ar savu ā€œatsaistiā€.

Tagad ir skaidrs, ka ar Å”o pieeju - izlaiÅ”anas puzles salikÅ”anu pakotnes lÄ«menÄ« - vienam galvenajam zaram nebija praktiskas nozÄ«mes. UzstādÄ«Å”ana ražoÅ”anā prasÄ«ja no pusotras lÄ«dz divām stundām roku darba. Labi, ka vismaz uzstādÄ«tāja lÄ«menÄ« tika noteikta objektu apstrādes kārtÄ«ba: lauki un struktÅ«ras tika ievadÄ«tas pirms tiem un procedÅ«rām. Tomēr tas darbojās tikai atseviŔķā paketē.

Å Ä«s pieejas loÄ£isks rezultāts bija obligātie instalācijas defekti objektu greizu versiju, nevajadzÄ«ga koda, trÅ«kstoÅ”u instrukciju un objektu neņemtās savstarpējās ietekmes veidā, kas pēc izlaiÅ”anas tika drudžaini novērsti. 

Pirmie atjauninājumi: veiciet montāžu un piegādi

Automatizācija sākās, pārsūtot kodu pa cauruli pa Ŕo marŔrutu:

  • Paņemt gatavo sÅ«tÄ«jumu no noliktavas;
  • Instalējiet to Ä«paŔā vidē;
  • palaist automātiskos testus;
  • Novērtējiet uzstādÄ«Å”anas rezultātu;
  • Izsauciet Å”o konveijeru testÄ“Å”anas komandas pusē.

Nākamajam konveijeram ir jāreÄ£istrē uzdevums programmā Jira un jāgaida, lÄ«dz komandas tiks izplatÄ«tas atlasÄ«tajām testÄ“Å”anas cilpām, kas ir atkarÄ«gas no uzdevuma ievieÅ”anas laika. Trigger - vēstule par gatavÄ«bu piegādei uz norādÄ«to adresi. Tas, protams, bija acÄ«mredzams kruÄ·is, bet man bija kaut kur jāsāk. 2019. gada maijā koda pārsÅ«tÄ«Å”ana sākās ar mÅ«su vides pārbaudēm. Process ir sācies, atliek tikai panākt, lai tas bÅ«tu pienācÄ«gā formā:

  • Katra modifikācija tiek veikta atseviŔķā atzarā, kas atbilst instalācijas pakotnei un saplÅ«st mērÄ·a galvenajā zarā;
  • Konveijera palaiÅ”anas aktivizētājs ir jaunas saistÄ«bas parādÄ«Å”anās galvenajā filiālē, izmantojot sapludināŔanas pieprasÄ«jumu, ko aizver iekŔējās komandas uzturētāji;
  • Krātuves tiek sinhronizētas reizi piecās minÅ«tēs;
  • Tiek uzsākta instalācijas pakotnes montāža - izmantojot no pārdevēja saņemto montētāju.

Pēc tam jau bija darbības, lai pārbaudītu un pārsūtītu kodu, palaistu cauruli un montētu mūsu pusē.

Å Ä« iespēja tika ieviesta jÅ«lijā. Pārejas grÅ«tÄ«bas izraisÄ«ja zināmu neapmierinātÄ«bu starp pārdevēju un priekŔējo lÄ«niju, taču nākamā mēneÅ”a laikā mums izdevās novērst visas rupjās malas un izveidot procesu starp komandām. Tagad mums ir montāža ar apņemÅ”anos un piegāde.
Augustā mums izdevās pabeigt pirmo atseviŔķas pakotnes instalÄ“Å”anu ražoÅ”anā, izmantojot mÅ«su konveijeru, un kopÅ” septembra bez izņēmuma visas individuālo neizlaižamo pakotņu instalācijas tika veiktas, izmantojot mÅ«su CD rÄ«ku. Turklāt mums izdevās sasniegt iekŔējo uzdevumu daļu 40% no laidiena sastāva ar mazāku komandu nekā pārdevējs ā€” tas ir neapÅ”aubāms panākums. Palika nopietnākais uzdevums - samontēt un uzstādÄ«t izlaidumu.

GalÄ«gais risinājums: kumulatÄ«vās instalācijas pakotnes 

Mēs lieliski sapratām, ka pārdevēja instrukciju skriptÄ“Å”ana ir tik ļoti automatizācija; mums bija jāpārdomā pats process. Risinājums bija acÄ«mredzams - savākt no izlaiduma filiāles kumulatÄ«vo krājumu ar visiem nepiecieÅ”amo versiju objektiem.

Mēs sākām ar koncepcijas pārbaudi: mēs manuāli salikām izlaiduma pakotni atbilstoÅ”i iepriekŔējās ievieÅ”anas saturam un instalējām to savā vidē. Viss izdevās, koncepcija izrādÄ«jās dzÄ«votspējÄ«ga. Pēc tam mēs atrisinājām problēmu par inicializācijas iestatÄ«jumu skriptÄ“Å”anu un to iekļauÅ”anu izpildē. Mēs sagatavojām jaunu pakotni un pārbaudÄ«jām to testÄ“Å”anas vidēs kontÅ«ru atjaunināŔanas ietvaros. InstalÄ“Å”ana bija veiksmÄ«ga, lai gan ar daudzām ievieÅ”anas komandas komentāriem. Bet galvenais ir tas, ka mums tika dota atļauja sākt ražoÅ”anu novembra izlaidumā ar mÅ«su montāžu.

Kad bija palicis nedaudz vairāk kā mēnesis, ar rokām atlasÄ«tās preces skaidri liecināja, ka laiks beidzas. Viņi nolēma uzbÅ«vēt no izlaiÅ”anas filiāles, bet kāpēc to vajadzētu atdalÄ«t? Mums nav Prod lÄ«dzÄ«ga, un esoŔās filiāles nav labas ā€” ir daudz nevajadzÄ«ga koda. Mums ir steidzami jāsamazina produktu patÄ«k, un tas ir vairāk nekā trÄ«s tÅ«kstoÅ”i saistÄ«bu. SalikÅ”ana ar rokām vispār nav risinājums. Mēs izveidojām skriptu, kas darbojas produkta instalÄ“Å”anas žurnālā un apkopo saistÄ«bas attiecÄ«bā uz filiāli. TreÅ”ajā reizē nostrādāja pareizi, un pēc ā€œapdares ar vÄ«liā€ zars bija gatavs. 

Mēs uzrakstÄ«jām paÅ”i savu celtnieku uzstādÄ«Å”anas pakotnei un pabeidzām to nedēļas laikā. Pēc tam mums bija jāmaina instalētājs no sistēmas pamata funkcionalitātes, jo tas ir atvērtā koda. Pēc vairākām pārbaudēm un modifikācijām rezultāts tika uzskatÄ«ts par veiksmÄ«gu. Pa to laiku izveidojās izlaiduma sastāvs, kura pareizai uzstādÄ«Å”anai bija nepiecieÅ”ams saskaņot testa ķēdi ar ražoÅ”anas ķēdi, un tam tika uzrakstÄ«ts atseviŔķs skripts.

Protams, par pirmo instalāciju bija daudz komentāru, taču kopumā kods darbojās. Un pēc apmēram treŔās instalÄ“Å”anas viss sāka izskatÄ«ties labi. AtseviŔķi tika uzraudzÄ«ta objektu kompozÄ«cijas kontrole un versiju kontrole manuālajā režīmā, kas Å”ajā posmā bija diezgan pamatoti.

Papildu izaicinājums bija lielais neizlaidumu skaits, kas bija jāņem vērā. Bet ar Prod līdzīgu filiāli un Rebase uzdevums kļuva caurspīdīgs.

Pirmo reizi ātri un bez kļūdām

Mēs piegājām izlaidumam ar optimistisku attieksmi un vairāk nekā duci veiksmÄ«gu instalāciju dažādās shēmās. Bet burtiski dienu pirms termiņa izrādÄ«jās, ka pārdevējs nebija pabeidzis darbu, lai sagatavotu izlaidumu instalÄ“Å”anai pieņemtajā veidā. Ja kāda iemesla dēļ mÅ«su versija nedarbojas, izlaiÅ”ana tiks pārtraukta. Turklāt ar mÅ«su pÅ«lēm, kas ir Ä«paÅ”i nepatÄ«kami. Mums nebija iespējas atkāpties. Tāpēc mēs pārdomājām alternatÄ«vas iespējas, sagatavojām rÄ«cÄ«bas plānus un sākām uzstādÄ«Å”anu.

PārsteidzoÅ”i, viss izlaidums, kas sastāv no vairāk nekā 800 objektiem, sākās pareizi, pirmo reizi un tikai 10 minÅ«tēs. Mēs pavadÄ«jām stundu, pārbaudot žurnālus, meklējot kļūdas, taču nevienu neatradām.

Visu nākamo dienu izlaiduma tērzÄ“Å”anā valdÄ«ja klusums: nebija ievieÅ”anas problēmu, greizas versijas vai ā€œnepiemērotaā€ koda. Tas bija pat kaut kā neērti. Vēlāk gan parādÄ«jās daži komentāri, taču, salÄ«dzinot ar citām sistēmām un iepriekŔējo pieredzi, to skaits un prioritāte bija manāmi mazāka.

Papildu efekts no kumulatÄ«vās ietekmes bija montāžas un testÄ“Å”anas kvalitātes paaugstināŔanās. Sakarā ar vairākām pilna laidiena instalācijām, bÅ«vÄ“Å”anas defekti un izvietoÅ”anas kļūdas tika konstatēti savlaicÄ«gi. TestÄ“Å”ana pilnās izlaiÅ”anas konfigurācijās ļāva papildus identificēt objektu savstarpējās ietekmes defektus, kas neparādÄ«jās inkrementālās instalācijas laikā. Tas noteikti bija veiksmÄ«gs, jo Ä«paÅ”i ņemot vērā mÅ«su 57% ieguldÄ«jumu izlaidumā.

Rezultāti un secinājumi

Mazāk nekā gada laikā mums izdevās:

  • Veidot pilnvērtÄ«gu iekŔējo attÄ«stÄ«bu, izmantojot eksotisku sistēmu;
  • Novērst kritisko atkarÄ«bu no pārdevēja;
  • Palaidiet CI/CD, lai iegÅ«tu ļoti nedraudzÄ«gu mantojumu;
  • Paaugstināt ievieÅ”anas procesus jaunā tehniskā lÄ«menÄ«;
  • Ievērojami samazināt izvietoÅ”anas laiku;
  • Ievērojami samazināt ievieÅ”anas kļūdu skaitu;
  • Ar pārliecÄ«bu pasludiniet sevi par vadoÅ”o attÄ«stÄ«bas ekspertu.

Protams, liela daļa no aprakstÄ«tā izskatās pēc atklātas muļķības, taču tās ir sistēmas iezÄ«mes un tajā pastāvoÅ”ie procesa ierobežojumi. Å obrÄ«d izmaiņas skāruÅ”as IS Profile produktus un pakalpojumus (meistarkonti, plastikāta kartes, krājkonti, darÄ«jums, naudas aizdevumi), taču potenciāli pieeju var attiecināt uz jebkuru IS, kurai ir izvirzÄ«ts DevOps prakÅ”u ievieÅ”anas uzdevums. KumulatÄ«vo modeli var droÅ”i replicēt turpmākajām ievieÅ”anām (tostarp neizlaistajām) no daudzām piegādēm.

Avots: www.habr.com

Pievieno komentāru