Praktikat e DevOps funksionojnë. Ne ishim të bindur për këtë vetë kur e reduktuam kohën e instalimit të lëshimit me 10 herë. Në sistemin e profilit FIS, të cilin ne përdorim në VTB, instalimi tani zgjat 90 minuta dhe jo 10. Koha e krijimit të lëshimit është ulur nga dy javë në dy ditë. Numri i defekteve të vazhdueshme të zbatimit ka rënë pothuajse në minimum. Për t'u larguar nga "puna manuale" dhe për të eliminuar varësinë nga shitësi, na u desh të punonim me paterica dhe të gjenim zgjidhje të papritura. Më poshtë prerjes është një histori e detajuar se si ndërtuam një zhvillim të brendshëm të plotë.
Prolog: DevOps është një filozofi
Gjatë vitit të kaluar, ne kemi bërë shumë punë për të organizuar zhvillimin e brendshëm dhe zbatimin e praktikave DevOps në VTB:
- Ne ndërtuam procese të brendshme zhvillimi për 12 sisteme;
- Ne lançuam 15 tubacione, katër prej të cilave u sollën në prodhim;
- Skenarët e testimit të automatizuar 1445;
- Ne zbatuam me sukses një numër publikimesh të përgatitura nga ekipet e brendshme.
Një nga më të vështirat për t'u organizuar zhvillimi i brendshëm dhe zbatimi i praktikave DevSecOps doli të ishte sistemi i profilit FIS - një procesor produkti me pakicë në një DBMS jo-relacionale. Megjithatë, ne ishim në gjendje të ndërtonim zhvillimin, të nisnim tubacionin, të instalonim paketa individuale pa lëshim në produkt dhe mësuam se si të montonim lëshimet. Detyra nuk ishte e lehtë, por interesante dhe pa kufizime të dukshme në zbatim: këtu është sistemi - ju duhet të ndërtoni një zhvillim të brendshëm. Kushti i vetëm është përdorimi i CD-së përpara një mjedisi produktiv.
Në fillim, algoritmi i zbatimit dukej i thjeshtë dhe i qartë:
- Ne zhvillojmë ekspertizën fillestare të zhvillimit dhe arrijmë një nivel të pranueshëm cilësie nga ekipi i kodit pa defekte të mëdha;
- Ne integrohemi në proceset ekzistuese sa më shumë që të jetë e mundur;
- Për të transferuar kodin midis fazave të dukshme, ne presim një tubacion dhe shtyjmë një nga skajet e tij në vazhdim.
Gjatë kësaj kohe, ekipi i zhvillimit të madhësisë së kërkuar duhet të zhvillojë aftësitë dhe të rrisë pjesën e kontributit të tij në publikimet në një nivel të pranueshëm. Dhe kjo është ajo, ne mund ta konsiderojmë detyrën të përfunduar.
Duket se kjo është një rrugë krejtësisht me efikasitet energjetik drejt rezultatit të kërkuar: këtu është DevOps, këtu janë metrikat e performancës së ekipit, këtu është ekspertiza e akumuluar... Por në praktikë, ne morëm një konfirmim tjetër që DevOps është ende rreth filozofisë , dhe jo "i bashkangjitur procesit gitlab, ansible, nexus dhe më poshtë në listë."
Pasi kemi analizuar edhe një herë planin e veprimit, kuptuam se po ndërtonim një lloj shitësi të jashtëm brenda vetes. Prandaj, algoritmit të përshkruar më sipër iu shtua riinxhinierimi i procesit, si dhe zhvillimi i ekspertizës përgjatë gjithë rrugës së zhvillimit për të arritur një rol udhëheqës në këtë proces. Jo opsioni më i lehtë, por kjo është rruga e zhvillimit ideologjikisht korrekt.
Ku fillon zhvillimi i brendshëm?
Nuk ishte sistemi më miqësor për të punuar. Arkitekturisht, ishte një DBMS e madhe jo-relacionale, e përbërë nga shumë objekte të veçanta të ekzekutueshme (skriptet, procedurat, grupet, etj.), të cilat thirreshin sipas nevojës dhe punonin në parimin e një kutie të zezë: merr një kërkesë dhe lëshon. nje pergjigje. Vështirësi të tjera që ia vlen të përmenden përfshijnë:
- Gjuhë ekzotike (MUMPS);
- Ndërfaqja e konsolës;
- Mungesa e integrimit me mjetet dhe kornizat popullore të automatizimit;
- Vëllimi i të dhënave në dhjetëra terabajt;
- Ngarkesa mbi 2 milion operacione në orë;
- Rëndësia - Biznes-kritike.
Në të njëjtën kohë, nuk kishte asnjë depo të kodit burim nga ana jonë. fare. Kishte dokumentacion, por të gjitha njohuritë dhe kompetencat kyçe ishin në anën e një organizate të jashtme.
Ne filluam të zotërojmë zhvillimin e sistemit pothuajse nga e para, duke marrë parasysh veçoritë e tij dhe shpërndarjen e ulët. Filloi në tetor 2018:
- Studioi dokumentacionin dhe bazat e gjenerimit të kodit;
- Ne studiuam kursin e shkurtër të zhvillimit të marrë nga shitësi;
- Zotëruar aftësitë fillestare të zhvillimit;
- Ne përpiluam një manual trajnimi për anëtarët e rinj të ekipit;
- Ne ramë dakord të përfshijmë ekipin në modalitetin "luftarak";
- Zgjidhet problemi me kontrollin e cilësisë së kodit;
- Ne organizuam një stendë për zhvillim.
Ne kaluam tre muaj duke zhvilluar ekspertizë dhe duke u zhytur në sistem, dhe që nga fillimi i vitit 2019, zhvillimi i brendshëm filloi lëvizjen e tij drejt një të ardhmeje të ndritur, ndonjëherë me vështirësi, por me besim dhe qëllim.
Migrimi i depove dhe autotestet
Detyra e parë e DevOps është depoja. Ne ramë shpejt dakord për sigurimin e aksesit, por ishte e nevojshme të migronim nga SVN-ja aktuale me një degë trungu në Git-in tonë të synuar me kalimin në një model të disa degëve dhe zhvillimin e Git Flow. Kemi gjithashtu 2 ekipe me infrastrukturën e tyre, plus një pjesë të ekipit të shitësve jashtë vendit. Më duhej të jetoja me dy Gits dhe të siguroja sinkronizimin. Në një situatë të tillë, ishte më e vogla nga dy të këqijat.
Migrimi i depove u shty në mënyrë të përsëritur; ai përfundoi vetëm në prill, me ndihmën e kolegëve të vijës së parë. Me Git Flow, vendosëm t'i mbajmë gjërat të thjeshta për fillim dhe u vendosëm në skemën klasike me rregullimin e drejtpërdrejtë, zhvillimin dhe lëshimin. Ata vendosën të braktisin mjeshtrin (aka prod-si). Më poshtë do të shpjegojmë pse ky opsion doli të ishte optimal për ne. Një depo e jashtme që i përket shitësit, e zakonshme për dy ekipe, u përdor si punëtor. Ai u sinkronizua me depon e brendshme sipas një plani. Tani me Git dhe Gitlab ishte e mundur të automatizonin proceset.
Çështja e autotesteve u zgjidh çuditërisht lehtësisht - na u dha një kornizë e gatshme. Duke marrë parasysh veçoritë e sistemit, thirrja e një operacioni të veçantë ishte një pjesë e kuptueshme e procesit të biznesit dhe në të njëjtën kohë shërbeu si një test njësi. E tëra që mbetej ishte përgatitja e të dhënave të testit dhe vendosja e rendit të dëshiruar të thirrjes së skripteve dhe vlerësimit të rezultateve. Me plotësimin e listës së skenarëve, të formuar në bazë të statistikave të funksionimit, kritikitetit të proceseve dhe metodologjisë ekzistuese të regresionit, testet automatike filluan të shfaqen. Tani mund të fillojmë ndërtimin e tubacionit.
Si ishte: modeli para automatizimit
Modeli ekzistues i procesit të zbatimit është një histori më vete. Çdo modifikim u transferua manualisht si një paketë e veçantë instalimi në rritje. Më pas erdhi regjistrimi manual në Jira dhe instalimi manual në mjedise. Për paketat individuale, gjithçka dukej qartë, por me përgatitjen e lëshimit, gjërat ishin më të ndërlikuara.
Montimi kryhej në nivel të dërgesave individuale, të cilat ishin objekte të pavarura. Çdo ndryshim është një dërgesë e re. Ndër të tjera, 60-70 versione teknike u shtuan në paketat 10-15 të përbërjes kryesore të lëshimit - versione të marra kur shtohet ose përjashtohet diçka nga publikimi dhe pasqyron ndryshimet në shitjet jashtë lëshimeve.
Objektet brenda dërgesave mbivendosen me njëri-tjetrin, veçanërisht në kodin e ekzekutueshëm, i cili ishte më pak se gjysma unik. Kishte shumë varësi si nga kodi i instaluar tashmë, ashtu edhe nga ai, instalimi i të cilit sapo ishte planifikuar.
Për të marrë versionin e kërkuar të kodit, ishte e nevojshme të ndiqesh me përpikëri rendin e instalimit, gjatë të cilit objektet u rishkruan fizikisht shumë herë, rreth 10-12 herë.
Pas instalimit të një grupi paketash, më duhej të ndiqja manualisht udhëzimet për të inicializuar cilësimet. Lëshimi u montua dhe u instalua nga shitësi. Përbërja e lëshimit u sqarua pothuajse para momentit të zbatimit, gjë që solli krijimin e paketave "shkëputëse". Si rezultat, një pjesë e konsiderueshme e furnizimeve kaluan nga lëshimi në lëshim me bishtin e vet të "shkëputjeve".
Tani është e qartë se me këtë qasje - montimi i enigmës së lëshimit në nivelin e paketës - një degë e vetme kryesore nuk kishte asnjë kuptim praktik. Instalimi në prodhim zgjati nga një orë e gjysmë deri në dy orë punë manuale. Është mirë që të paktën në nivelin e instaluesit u specifikua rendi i përpunimit të objektit: fushat dhe strukturat u futën përpara të dhënave për to dhe procedurat. Sidoqoftë, kjo funksionoi vetëm brenda një pakete të veçantë.
Rezultati logjik i kësaj qasjeje ishin defektet e detyrueshme të instalimit në formën e versioneve të shtrembëruara të objekteve, kodit të panevojshëm, udhëzimeve të munguara dhe ndikimeve reciproke të objekteve, të cilat u eliminuan në mënyrë të ethshme pas lëshimit.
Përditësimet e para: kryeni montimin dhe dorëzimin
Automatizimi filloi duke transmetuar kodin përmes një tubi përgjatë kësaj rruge:
- Merrni dorëzimin e përfunduar nga ruajtja;
- Instaloni atë në një mjedis të dedikuar;
- Kryeni autoteste;
- Vlerësoni rezultatin e instalimit;
- Thirrni tubacionin e mëposhtëm në anën e komandës së testimit.
Gazsjellësi tjetër duhet të regjistrojë detyrën në Jira dhe të presë që komandat të shpërndahen në unazat e përzgjedhura të testimit, të cilat varen nga koha e zbatimit të detyrës. Shkaktësi - një letër në lidhje me gatishmërinë për dorëzim në një adresë të caktuar. Kjo, natyrisht, ishte një patericë e dukshme, por duhej të filloja diku. Në maj 2019, transferimi i kodit filloi me kontrollet në mjediset tona. Procesi ka filluar, gjithçka që mbetet është ta sjellim atë në një formë të mirë:
- Çdo modifikim kryhet në një degë të veçantë, e cila korrespondon me paketën e instalimit dhe bashkohet në degën kryesore të synuar;
- Shkaktësi i nisjes së tubacionit është shfaqja e një commit të ri në degën kryesore nëpërmjet një kërkese për bashkim, e cila mbyllet nga mirëmbajtësit nga ekipi i brendshëm;
- Depot sinkronizohen një herë në pesë minuta;
- Fillon montimi i paketës së instalimit - duke përdorur montuesin e marrë nga shitësi.
Pas kësaj, kishte tashmë hapa ekzistues për të kontrolluar dhe transferuar kodin, për të nisur tubin dhe për të montuar në anën tonë.
Ky opsion u lançua në korrik. Vështirësitë e tranzicionit rezultuan në pakënaqësi midis shitësit dhe vijës së parë, por gjatë muajit të ardhshëm arritëm të hiqnim të gjitha skajet e vrazhda dhe të krijonim një proces midis ekipeve. Tani kemi montim me zotim dhe dorëzim.
Në gusht, arritëm të përfundonim instalimin e parë të një pakete të veçantë për prodhimin duke përdorur tubacionin tonë, dhe që nga shtatori, pa përjashtim, të gjitha instalimet e paketave individuale pa lëshim u kryen përmes mjetit tonë CD. Për më tepër, ne arritëm të arrijmë një pjesë të detyrave të brendshme në 40% të përbërjes së lëshimit me një ekip më të vogël se shitësi - ky është një sukses i caktuar. Detyra më serioze mbeti - montimi dhe instalimi i lëshimit.
Zgjidhja përfundimtare: paketat kumulative të instalimit
Ne e kuptuam shumë mirë se shkrimi i udhëzimeve të shitësit ishte një automatizim kaq i madh; ne duhej të rimendonim vetë procesin. Zgjidhja ishte e qartë - të mblidhej një furnizim kumulativ nga dega e lëshimit me të gjitha objektet e versioneve të kërkuara.
Ne filluam me vërtetimin e konceptit: ne montuam me dorë paketën e lëshimit sipas përmbajtjes së zbatimit të kaluar dhe e instaluam atë në mjediset tona. Gjithçka funksionoi, koncepti doli të ishte i zbatueshëm. Më pas, ne zgjidhëm çështjen e skriptimit të cilësimeve të inicializimit dhe përfshirjes së tyre në commit. Ne përgatitëm një paketë të re dhe e testuam atë në mjediset e testimit si pjesë e përditësimit të konturit. Instalimi ishte i suksesshëm, megjithëse me një gamë të gjerë komentesh nga ekipi i zbatimit. Por gjëja kryesore është se na u dha leja për të hyrë në prodhim në versionin e nëntorit me asamblenë tonë.
Me pak më shumë se një muaj të mbetur, furnizimet e zgjedhura me dorë lë të kuptohet qartë se koha po mbaronte. Ata vendosën ta bëjnë ndërtimin nga dega e lëshimit, por pse duhet të ndahet? Ne nuk kemi një Prod-si dhe degët ekzistuese nuk janë të mira - ka shumë kode të panevojshme. Na duhet urgjentisht të shkurtojmë prod-likes, dhe kjo është mbi tre mijë angazhime. Montimi me dorë nuk është aspak një opsion. Ne skicuam një skript që kalon nëpër regjistrin e instalimit të produktit dhe mbledh detyrimet në degë. Herën e tretë funksionoi si duhet, dhe pasi "përfundoi me një skedar" dega ishte gati.
Ne shkruam ndërtuesin tonë për paketën e instalimit dhe e përfunduam brenda një jave. Më pas na u desh të modifikonim instaluesin nga funksionaliteti kryesor i sistemit, pasi është me burim të hapur. Pas një sërë kontrollesh dhe modifikimesh, rezultati u konsiderua i suksesshëm. Ndërkohë, përbërja e lëshimit mori formë, për instalimin e saktë të së cilës ishte e nevojshme të përafrohet qarku i provës me atë të prodhimit, dhe për këtë u shkrua një skenar i veçantë.
Natyrisht, kishte shumë komente për instalimin e parë, por në përgjithësi kodi funksionoi. Dhe pas instalimit të tretë, gjithçka filloi të dukej mirë. Kontrolli i përbërjes dhe kontrolli i versionit të objekteve u monitoruan veçmas në modalitetin manual, gjë që në këtë fazë ishte mjaft e justifikuar.
Një sfidë shtesë ishte numri i madh i mos publikimeve që duheshin marrë parasysh. Por me degën Prod-like dhe Rebase, detyra u bë transparente.
Hera e parë, shpejt dhe pa gabime
Ne iu afruam lëshimit me një qëndrim optimist dhe më shumë se një duzinë instalimesh të suksesshme në qarqe të ndryshme. Por fjalë për fjalë një ditë para afatit, doli që shitësi nuk e kishte përfunduar punën për të përgatitur lëshimin për instalim në mënyrën e pranuar. Nëse për ndonjë arsye ndërtimi ynë nuk funksionon, lëshimi do të ndërpritet. Për më tepër, përmes përpjekjeve tona, gjë që është veçanërisht e pakëndshme. Nuk kishim se si të tërhiqem. Prandaj, ne menduam për opsione alternative, përgatitëm plane veprimi dhe filluam instalimin.
Çuditërisht, i gjithë lëshimi, i përbërë nga më shumë se 800 objekte, filloi në mënyrë korrekte, herën e parë dhe në vetëm 10 minuta. Kaluam një orë duke kontrolluar regjistrat duke kërkuar gabime, por nuk gjetëm asnjë.
Gjithë ditën tjetër pati heshtje në bisedën e lëshimit: pa probleme zbatimi, versione të shtrembëruara ose kod "i papërshtatshëm". Madje ishte disi e sikletshme. Më vonë, u shfaqën disa komente, por në krahasim me sistemet e tjera dhe përvojën e mëparshme, numri dhe përparësia e tyre ishin dukshëm më të ulëta.
Një efekt shtesë nga efekti kumulativ ishte një rritje në cilësinë e montimit dhe testimit. Për shkak të instalimeve të shumta të lëshimit të plotë, defektet e ndërtimit dhe gabimet e vendosjes u identifikuan në kohën e duhur. Testimi në konfigurimet e lëshimit të plotë bëri të mundur identifikimin shtesë të defekteve në ndikimin e ndërsjellë të objekteve që nuk u shfaqën gjatë instalimeve në rritje. Ishte padyshim një sukses, veçanërisht duke pasur parasysh kontributin tonë prej 57% në publikim.
Rezultatet dhe përfundimet
Në më pak se një vit arritëm të:
- Ndërtoni një zhvillim të brendshëm të plotë duke përdorur një sistem ekzotik;
- Eliminoni varësinë kritike të shitësit;
- Hapni CI/CD për një trashëgimi shumë jo miqësore;
- Ngritja e proceseve të zbatimit në një nivel të ri teknik;
- Ulni ndjeshëm kohën e vendosjes;
- Ulja e ndjeshme e numrit të gabimeve në zbatim;
- Shpallni me besim veten si një ekspert kryesor zhvillimi.
Natyrisht, shumë nga ato që përshkruhen duken si mut, por këto janë tiparet e sistemit dhe kufizimet e procesit që ekzistojnë në të. Për momentin, ndryshimet prekën produktet dhe shërbimet e Profilit IS (llogaritë kryesore, kartat plastike, llogaritë e kursimit, ruajtje, kredi në para), por potencialisht qasja mund të zbatohet për çdo IS për të cilin është vendosur detyra e zbatimit të praktikave të DevOps. Modeli kumulativ mund të përsëritet në mënyrë të sigurt për implementimet e mëvonshme (përfshirë ato që nuk lëshohen) nga shumë dërgesa.
Burimi: www.habr.com