Gumagana ang mga kasanayan sa DevOps. Kami mismo ay kumbinsido dito nang bawasan namin ang oras ng pag-install ng release ng 10 beses. Sa system ng FIS Profile, na ginagamit namin sa VTB, ang pag-install ngayon ay tumatagal ng 90 minuto sa halip na 10. Bumaba ang oras ng pagbuo ng release mula dalawang linggo hanggang dalawang araw. Ang bilang ng patuloy na mga depekto sa pagpapatupad ay bumaba sa halos isang minimum. Upang makalayo sa "manual na paggawa" at alisin ang pag-asa sa vendor, kinailangan naming magtrabaho kasama ang mga saklay at maghanap ng mga hindi inaasahang solusyon. Sa ibaba ng cut ay isang detalyadong kuwento tungkol sa kung paano namin binuo ang isang ganap na panloob na pag-unlad.
Prologue: Ang DevOps ay isang pilosopiya
Sa nakalipas na taon, gumawa kami ng maraming trabaho upang ayusin ang panloob na pag-unlad at pagpapatupad ng mga kasanayan sa DevOps sa VTB:
- Nagtayo kami ng mga proseso ng panloob na pag-unlad para sa 12 system;
- Naglunsad kami ng 15 pipeline, apat sa mga ito ay dinala sa produksyon;
- Naka-automate na 1445 na mga senaryo ng pagsubok;
- Matagumpay naming naipatupad ang ilang release na inihanda ng mga in-house na team.
Ang isa sa pinakamahirap na ayusin ang inhouse development at pagpapatupad ng mga kasanayan sa DevSecOps ay ang FIS Profile system - isang retail product processor sa isang non-relational na DBMS. Gayunpaman, nagawa naming buuin ang development, ilunsad ang pipeline, i-install ang mga indibidwal na non-release na package sa produkto, at natutunan kung paano mag-assemble ng mga release. Ang gawain ay hindi madali, ngunit kawili-wili at walang malinaw na mga paghihigpit sa pagpapatupad: narito ang sistema - kailangan mong bumuo ng isang in-house na pag-unlad. Ang tanging kundisyon ay gamitin ang CD bago ang isang produktibong kapaligiran.
Sa una, ang algorithm ng pagpapatupad ay tila simple at malinaw:
- Bumubuo kami ng paunang kadalubhasaan sa pag-unlad at nakakamit ang isang katanggap-tanggap na antas ng kalidad mula sa pangkat ng code na walang malalaking depekto;
- Sumasama kami sa mga kasalukuyang proseso hangga't maaari;
- Upang ilipat ang code sa pagitan ng mga malinaw na yugto, pinutol namin ang isang pipeline at itulak ang isa sa mga dulo nito sa pagpapatuloy.
Sa panahong ito, ang pangkat ng pagbuo ng kinakailangang laki ay dapat bumuo ng mga kasanayan at taasan ang bahagi ng kontribusyon nito sa mga release sa isang katanggap-tanggap na antas. At iyon lang, maaari nating isaalang-alang ang gawaing natapos.
Tila ito ay isang ganap na matipid sa enerhiya na landas patungo sa kinakailangang resulta: narito ang DevOps, narito ang mga sukatan ng pagganap ng koponan, narito ang naipon na kadalubhasaan... Ngunit sa pagsasagawa, nakatanggap kami ng isa pang kumpirmasyon na ang DevOps ay tungkol pa rin sa pilosopiya , at hindi "naka-attach sa proseso ng gitlab, ansible, nexus at higit pa sa ibaba ng listahan."
Sa muling pagsusuri sa plano ng aksyon, napagtanto namin na kami ay nagtatayo ng isang uri ng outsource vendor sa loob ng aming sarili. Samakatuwid, ang proseso ng reengineering ay idinagdag sa algorithm na inilarawan sa itaas, pati na rin ang pagbuo ng kadalubhasaan sa buong ruta ng pag-unlad upang makamit ang isang nangungunang papel sa prosesong ito. Hindi ang pinakamadaling opsyon, ngunit ito ang landas ng tamang pag-unlad sa ideolohiya.
Saan nagsisimula ang inhouse development?
Ito ay hindi ang pinaka-friendly na sistema upang gumana sa. Sa arkitektura, isa itong malaking non-relational na DBMS, na binubuo ng maraming magkakahiwalay na executable object (mga script, procedure, batch, atbp.), na tinawag kung kinakailangan, at nagtrabaho sa prinsipyo ng isang black box: tumatanggap ito ng kahilingan at mga isyu. isang tugon. Ang iba pang mga paghihirap na dapat tandaan ay kinabibilangan ng:
- Exotic na wika (MUMPS);
- Interface ng console;
- Kakulangan ng pagsasama sa mga sikat na tool at framework ng automation;
- Dami ng data sa sampu-sampung terabytes;
- Pag-load ng higit sa 2 milyong mga operasyon kada oras;
- Kahalagahan - Mahalaga sa Negosyo.
Kasabay nito, walang source code repository sa aming panig. Sa lahat. Mayroong dokumentasyon, ngunit lahat ng pangunahing kaalaman at kakayahan ay nasa panig ng isang panlabas na organisasyon.
Sinimulan naming mastering ang pagbuo ng system halos mula sa simula, isinasaalang-alang ang mga tampok nito at mababang pamamahagi. Nagsimula noong Oktubre 2018:
- Pinag-aralan ang dokumentasyon at mga pangunahing kaalaman sa pagbuo ng code;
- Pinag-aralan namin ang maikling kurso sa pag-unlad na natanggap mula sa vendor;
- Pinagkadalubhasaan ang mga kasanayan sa paunang pag-unlad;
- Nag-compile kami ng training manual para sa mga bagong miyembro ng team;
- Sumang-ayon kaming isama ang koponan sa mode na "combat";
- Nalutas ang isyu sa kontrol sa kalidad ng code;
- Nag-organisa kami ng paninindigan para sa kaunlaran.
Tatlong buwan kaming gumugol sa pagbuo ng kadalubhasaan at paglubog ng aming sarili sa system, at mula sa simula ng 2019, sinimulan ng inhouse development ang paggalaw nito tungo sa isang magandang kinabukasan, kung minsan ay nahihirapan, ngunit may kumpiyansa at may layunin.
Paglipat ng repository at mga autotest
Ang unang gawain ng DevOps ay ang repositoryo. Mabilis kaming sumang-ayon sa pagbibigay ng access, ngunit kinakailangan na lumipat mula sa kasalukuyang SVN na may isang trunk branch patungo sa aming target na Git kasama ang paglipat sa isang modelo ng ilang sangay at pagbuo ng Git Flow. Mayroon din kaming 2 team na may sariling imprastraktura, kasama ang bahagi ng team ng vendor sa ibang bansa. Kinailangan kong mamuhay kasama ang dalawang Gits at tiyakin ang pag-synchronize. Sa ganoong sitwasyon, ito ang mas maliit sa dalawang kasamaan.
Ang paglipat ng repository ay paulit-ulit na ipinagpaliban; natapos lamang ito noong Abril, sa tulong ng mga kasamahan mula sa front line. Sa Git Flow, napagpasyahan naming panatilihing simple ang mga bagay para sa isang panimula at tumira sa klasikong scheme na may hotfix, bumuo at magpalabas. Nagpasya silang talikuran si master (aka prod-like). Sa ibaba ay ipapaliwanag namin kung bakit naging pinakamainam para sa amin ang pagpipiliang ito. Ang isang panlabas na imbakan na pagmamay-ari ng vendor, karaniwan para sa dalawang koponan, ay ginamit bilang isang manggagawa. Naka-synchronize ito sa panloob na imbakan ayon sa isang iskedyul. Ngayon sa Git at Gitlab posible na i-automate ang mga proseso.
Ang isyu ng mga autotest ay madaling nalutas - binigyan kami ng isang handa na balangkas. Isinasaalang-alang ang mga kakaiba ng system, ang pagtawag sa isang hiwalay na operasyon ay isang naiintindihan na bahagi ng proseso ng negosyo at sa parehong oras ay nagsilbi bilang isang pagsubok sa yunit. Ang natitira na lang ay ihanda ang data ng pagsubok at itakda ang nais na pagkakasunud-sunod ng pagtawag sa mga script at pagsusuri ng mga resulta. Habang napunan ang listahan ng mga senaryo, na nabuo batay sa mga istatistika ng operasyon, ang pagiging kritikal ng mga proseso at ang umiiral na pamamaraan ng pagbabalik, nagsimulang lumitaw ang mga awtomatikong pagsubok. Ngayon ay maaari na nating simulan ang pagbuo ng pipeline.
Paano ito: ang modelo bago ang automation
Ang umiiral na modelo ng proseso ng pagpapatupad ay isang hiwalay na kuwento. Ang bawat pagbabago ay manu-manong inilipat bilang isang hiwalay na incremental installation package. Sumunod ay manu-manong pagpaparehistro sa Jira at manu-manong pag-install sa mga kapaligiran. Para sa mga indibidwal na pakete, ang lahat ay mukhang malinaw, ngunit sa paghahanda ng paglabas, ang mga bagay ay mas kumplikado.
Ang pagpupulong ay isinasagawa sa antas ng mga indibidwal na paghahatid, na mga independiyenteng bagay. Anumang pagbabago ay isang bagong paghahatid. Sa iba pang mga bagay, 60β70 teknikal na bersyon ang idinagdag sa 10-15 pakete ng pangunahing komposisyon ng release - mga bersyon na nakuha kapag nagdagdag o nagbubukod ng isang bagay mula sa release at nagpapakita ng mga pagbabago sa mga benta sa labas ng mga release.
Ang mga bagay sa loob ng mga paghahatid ay nag-overlap sa isa't isa, lalo na sa executable code, na wala pang kalahating kakaiba. Mayroong maraming mga dependency pareho sa naka-install na code at sa isa na ang pag-install ay pinlano lang.
Upang makuha ang kinakailangang bersyon ng code, kinakailangan na mahigpit na sundin ang pagkakasunud-sunod ng pag-install, kung saan ang mga bagay ay pisikal na muling isinulat nang maraming beses, mga 10-12 beses.
Pagkatapos mag-install ng isang batch ng mga pakete, kailangan kong manu-manong sundin ang mga tagubilin upang masimulan ang mga setting. Ang paglabas ay binuo at na-install ng vendor. Ang komposisyon ng paglabas ay nilinaw halos bago ang sandali ng pagpapatupad, na nagsasangkot ng paglikha ng mga "decoupling" na mga pakete. Bilang isang resulta, ang isang makabuluhang bahagi ng mga supply ay lumipat mula sa paglabas hanggang sa paglabas na may sariling buntot ng "decouplings".
Ngayon ay malinaw na sa diskarteng ito - pag-assemble ng release puzzle sa antas ng package - ang isang solong master branch ay walang praktikal na kahulugan. Ang pag-install sa produksyon ay tumagal mula isa at kalahati hanggang dalawang oras ng manu-manong paggawa. Mabuti na hindi bababa sa antas ng installer ang pagkakasunud-sunod ng pagproseso ng bagay: ang mga patlang at istruktura ay ipinasok bago ang data para sa kanila at mga pamamaraan. Gayunpaman, ito ay nagtrabaho lamang sa loob ng isang hiwalay na pakete.
Ang lohikal na resulta ng diskarteng ito ay ang obligadong mga depekto sa pag-install sa anyo ng mga baluktot na bersyon ng mga bagay, hindi kinakailangang code, nawawalang mga tagubilin at hindi napag-alaman para sa magkaparehong impluwensya ng mga bagay, na kung saan ay feverishly eliminated pagkatapos ng release.
Mga unang update: gumawa ng pagpupulong at paghahatid
Nagsimula ang automation sa pamamagitan ng pagpapadala ng code sa pamamagitan ng pipe sa rutang ito:
- Kunin ang natapos na paghahatid mula sa imbakan;
- I-install ito sa isang nakatuong kapaligiran;
- Magpatakbo ng mga autotest;
- Suriin ang resulta ng pag-install;
- Tawagan ang sumusunod na pipeline sa gilid ng testing command.
Ang susunod na pipeline ay dapat na irehistro ang gawain sa Jira at maghintay para sa mga utos na ipamahagi sa mga piling pagsubok na loop, na nakadepende sa timing ng pagpapatupad ng gawain. Trigger - isang liham tungkol sa kahandaan para sa paghahatid sa isang ibinigay na address. Ito, siyempre, ay isang malinaw na saklay, ngunit kailangan kong magsimula sa isang lugar. Noong Mayo 2019, nagsimula ang paglilipat ng code sa mga pagsusuri sa aming mga kapaligiran. Nagsimula na ang proseso, ang natitira na lang ay dalhin ito sa disenteng hugis:
- Ang bawat pagbabago ay isinasagawa sa isang hiwalay na sangay, na tumutugma sa pakete ng pag-install at sumasama sa target na master branch;
- Ang pipeline launch trigger ay ang paglitaw ng isang bagong commit sa master branch sa pamamagitan ng kahilingan sa pagsasama, na isinara ng mga maintainer mula sa inhouse na team;
- Ang mga repository ay naka-synchronize isang beses bawat limang minuto;
- Ang pagpupulong ng pakete ng pag-install ay nagsimula - gamit ang assembler na natanggap mula sa vendor.
Pagkatapos nito, mayroon nang mga umiiral na hakbang upang suriin at ilipat ang code, upang ilunsad ang tubo at mag-ipon sa aming panig.
Ang pagpipiliang ito ay inilunsad noong Hulyo. Ang mga paghihirap ng paglipat ay nagresulta sa ilang kawalang-kasiyahan sa pagitan ng vendor at sa front line, ngunit sa susunod na buwan ay nagawa naming alisin ang lahat ng mga magaspang na gilid at magtatag ng isang proseso sa mga koponan. Mayroon na tayong assembly by commit at delivery.
Noong Agosto, nagawa naming kumpletuhin ang unang pag-install ng isang hiwalay na pakete sa produksyon gamit ang aming pipeline, at mula noong Setyembre, nang walang pagbubukod, ang lahat ng mga pag-install ng mga indibidwal na non-release na pakete ay isinagawa sa pamamagitan ng aming CD tool. Bilang karagdagan, nagawa naming makamit ang isang bahagi ng mga inhouse na gawain sa 40% ng komposisyon ng pagpapalabas na may mas maliit na koponan kaysa sa vendor - ito ay isang tiyak na tagumpay. Ang pinakaseryosong gawain ay nanatili - upang tipunin at i-install ang paglabas.
Ang huling solusyon: pinagsama-samang mga pakete ng pag-install
Naunawaan naming lubos na ang pag-script ng mga tagubilin ng vendor ay isang napakagandang automation; kailangan naming muling pag-isipan ang proseso mismo. Ang solusyon ay halata - upang mangolekta ng pinagsama-samang supply mula sa release branch kasama ang lahat ng mga bagay ng mga kinakailangang bersyon.
Nagsimula kami sa patunay ng konsepto: ginawa naming kamay ang release package ayon sa mga nilalaman ng nakaraang pagpapatupad at na-install ito sa aming mga kapaligiran. Ang lahat ay nagtrabaho, ang konsepto ay naging mabubuhay. Susunod, nalutas namin ang isyu ng pag-script ng mga setting ng pagsisimula at pagsasama ng mga ito sa commit. Naghanda kami ng bagong package at sinubukan ito sa mga testing environment bilang bahagi ng contour update. Ang pag-install ay matagumpay, kahit na may malawak na hanay ng mga komento mula sa pangkat ng pagpapatupad. Ngunit ang pangunahing bagay ay binigyan kami ng go-ahead na pumunta sa produksyon sa paglabas ng Nobyembre kasama ang aming pagpupulong.
Mahigit isang buwan na lang ang natitira, malinaw na ipinahiwatig ng mga napiling supply na malapit na ang oras. Nagpasya silang gawin ang build mula sa release branch, ngunit bakit ito dapat paghiwalayin? Wala kaming katulad ng Prod, at hindi maganda ang mga umiiral na branch - maraming hindi kinakailangang code. Kailangan na nating i-cut ang mga prod-like, at ito ay higit sa tatlong libong commit. Ang pagpupulong sa pamamagitan ng kamay ay hindi isang opsyon sa lahat. Nag-sketch kami ng script na tumatakbo sa log ng pag-install ng produkto at nangongolekta ng mga commit sa branch. Sa ikatlong pagkakataon ay gumana ito nang tama, at pagkatapos ng "pagtatapos sa isang file" ang sangay ay handa na.
Sumulat kami ng sarili naming tagabuo para sa package ng pag-install at natapos ito sa loob ng isang linggo. Pagkatapos ay kinailangan naming baguhin ang installer mula sa pangunahing functionality ng system, dahil open-source ito. Matapos ang isang serye ng mga pagsusuri at pagbabago, ang resulta ay itinuturing na matagumpay. Samantala, ang komposisyon ng paglabas ay nabuo, para sa tamang pag-install kung saan kinakailangan upang ihanay ang test circuit sa produksyon, at isang hiwalay na script ang isinulat para dito.
Naturally, mayroong maraming mga komento tungkol sa unang pag-install, ngunit sa pangkalahatan ay gumana ang code. At pagkatapos ng tungkol sa ikatlong pag-install ang lahat ay nagsimulang magmukhang maganda. Ang kontrol sa komposisyon at kontrol ng bersyon ng mga bagay ay hiwalay na sinusubaybayan sa manu-manong mode, na sa yugtong ito ay lubos na makatwiran.
Ang isang karagdagang hamon ay ang malaking bilang ng mga hindi pagpapalabas na kailangang isaalang-alang. Ngunit sa mala-Prod na sangay at Rebase, naging transparent ang gawain.
First time, mabilis at walang error
Nilapitan namin ang paglabas na may positibong saloobin at higit sa isang dosenang matagumpay na pag-install sa iba't ibang mga circuit. Ngunit literal isang araw bago ang deadline, lumabas na ang vendor ay hindi natapos ang trabaho upang ihanda ang paglabas para sa pag-install sa tinatanggap na paraan. Kung sa ilang kadahilanan ay hindi gagana ang aming build, maaabala ang paglabas. Bukod dito, sa pamamagitan ng aming mga pagsisikap, na lalong hindi kasiya-siya. Wala kaming paraan para umatras. Samakatuwid, nag-isip kami ng mga alternatibong opsyon, naghanda ng mga plano sa pagkilos at nagsimulang mag-install.
Nakakagulat, ang buong paglabas, na binubuo ng higit sa 800 mga bagay, ay nagsimula nang tama, sa unang pagkakataon at sa loob lamang ng 10 minuto. Isang oras kaming nagsuri sa mga log na naghahanap ng mga error, ngunit wala kaming nakita.
Sa buong susunod na araw ay nagkaroon ng katahimikan sa release chat: walang mga problema sa pagpapatupad, mga baluktot na bersyon o "hindi naaangkop" na code. Kahit papaano naging awkward. Nang maglaon, lumitaw ang ilang mga komento, ngunit kumpara sa iba pang mga system at nakaraang karanasan, ang kanilang bilang at priyoridad ay kapansin-pansing mas mababa.
Ang isang karagdagang epekto mula sa pinagsama-samang epekto ay isang pagtaas sa kalidad ng pagpupulong at pagsubok. Dahil sa maraming pag-install ng buong release, natukoy ang mga depekto sa build at mga error sa deployment sa isang napapanahong paraan. Ang pagsubok sa mga kumpletong pagsasaayos ng release ay naging posible upang dagdagan ang pagtukoy ng mga depekto sa magkaparehong impluwensya ng mga bagay na hindi lumitaw sa panahon ng mga incremental na pag-install. Talagang isang tagumpay ito, lalo na dahil sa aming 57% na kontribusyon sa paglabas.
Buod at Konklusyon
Sa wala pang isang taon, nagawa naming:
- Bumuo ng isang ganap na panloob na pag-unlad gamit ang isang kakaibang sistema;
- Tanggalin ang kritikal na dependency sa vendor;
- Ilunsad ang CI/CD para sa isang hindi magiliw na pamana;
- Itaas ang mga proseso ng pagpapatupad sa isang bagong teknikal na antas;
- Makabuluhang bawasan ang oras ng pag-deploy;
- Makabuluhang bawasan ang bilang ng mga error sa pagpapatupad;
- Kumpiyansa na ipahayag ang iyong sarili bilang isang nangungunang eksperto sa pag-unlad.
Siyempre, ang karamihan sa inilarawan ay mukhang tahasang kalokohan, ngunit ito ang mga tampok ng system at ang mga limitasyon sa proseso na umiiral dito. Sa ngayon, naapektuhan ng mga pagbabago ang mga produkto at serbisyo ng IS Profile (mga master account, plastic card, savings account, escrow, cash loan), ngunit posibleng mailapat ang diskarte sa anumang IS kung saan nakatakda ang gawain ng pagpapatupad ng mga kasanayan sa DevOps. Ang pinagsama-samang modelo ay maaaring ligtas na kopyahin para sa mga kasunod na pagpapatupad (kabilang ang mga hindi inilabas) mula sa maraming paghahatid.
Pinagmulan: www.habr.com