DevOps praktikek funtzionatzen dute. Guk honetaz konbentzituta geunden oharra instalatzeko denbora 10 aldiz murriztu genuenean. VTBn erabiltzen dugun FIS Profile sisteman, instalazioak 90 minutu behar ditu orain, 10 baino gehiago. Bi astetik bi egun izatera jaitsi da kaleratzea eraikitzeko denbora. Inplementazio akats iraunkorren kopurua ia gutxienera jaitsi da. βEskuzko lanetikβ aldendu eta saltzailearekiko menpekotasuna kentzeko, makuluekin lan egin eta ustekabeko irtenbideak aurkitu behar izan ditugu. Ebakiaren azpian barne garapen osoa nola eraiki genuen buruzko istorio zehatza dago.
Hitzaurrea: DevOps filosofia bat da
Azken urtean, lan handia egin dugu VTBn DevOps praktiken barne garapena eta ezarpena antolatzeko:
- 12 sistemetarako barne garapen prozesuak eraiki genituen;
- 15 hodi jarri genituen martxan, eta horietatik lau ekoizpenera eraman zituzten;
- 1445 proba-eszenatoki automatizatuak;
- Etxeko taldeek prestatutako hainbat argitalpen arrakastaz inplementatu ditugu.
DevSecOps praktiken barneko garapena eta inplementazioa antolatzeko zailenetako bat FIS Profile sistema izan zen - erlaziorik gabeko DBMS batean txikizkako produktuen prozesadorea. Hala ere, garapena eraiki, kanalizazioa abiarazi, produktuan kaleratu gabeko pakete indibidualak instalatu eta bertsioak muntatzen ikasi genuen. Zeregin ez zen erraza, baina interesgarria eta inplementazioan murrizketa nabaririk gabea: hona sistema: barne-garapen bat eraiki behar duzu. Baldintza bakarra CDa ingurune produktibo baten aurretik erabiltzea da.
Hasieran, ezarpen-algoritmoa sinplea eta argia zirudien:
- Hasierako garapen-esperientzia garatzen dugu eta kode-taldearen kalitate-maila onargarria lortzen dugu akats larririk gabe;
- Dauden prozesuetan ahalik eta gehien integratzen gara;
- Ageriko faseen artean kodea transferitzeko, kanalizazio bat moztu eta bere muturretako bat jarraipenera bultzatzen dugu.
Denbora horretan, behar den tamainako garapen-taldeak trebetasunak garatu behar ditu eta bertsioetara egindako ekarpenaren kuota maila onartzeraino handitu behar du. Eta kitto, zeregina amaitutzat jo dezakegu.
Behar den emaitza lortzeko bide energetikoki guztiz eraginkorra dela dirudi: hona hemen DevOps, hona hemen taldearen errendimenduaren neurketak, hona hemen pilatutako espezializazioa... Baina praktikan, DevOps filosofiari buruzkoa dela beste baieztapen bat jaso genuen. , eta ez "gitlab prozesura erantsita, ansible, nexus eta zerrendan beherago".
Ekintza plana berriro aztertu ondoren, konturatu ginen gure baitan azpikontratatutako saltzaile moduko bat eraikitzen ari ginela. Hori dela eta, goian deskribatutako algoritmoari prozesuen biringeniaritza gehitu zitzaion, baita garapen-ibilbide osoan zehar adituen garapena prozesu honetan protagonismoa lortzeko. Ez da aukerarik errazena, baina hau da garapen ideologikoki zuzenaren bidea.
Non hasten da barneko garapena?
Ez zen lan egiteko sistemarik atseginena. Arkitektura aldetik, DBMS ez-erlazional handi bat zen, objektu exekutagarri asko (scriptak, prozedurak, loteak, etab.) osatzen zutenak, behar bezala deitzen zirenak, eta kutxa beltz baten printzipioan lan egiten zuen: eskaera eta arazoak jasotzen ditu. erantzun bat. Aipatzekoak diren beste zailtasun batzuk hauek dira:
- Hizkuntza exotikoa (MUMPS);
- Kontsolaren interfazea;
- Automatizazio tresna eta esparru ezagunekin integrazio falta;
- Datuen bolumena hamarnaka terabytetan;
- Orduko 2 milioi eragiketa baino gehiagoko karga;
- Garrantzitsua - Negozio-kritikoa.
Aldi berean, gure aldean ez zegoen iturburu-kodeen biltegirik. Batere. Dokumentazioa zegoen, baina funtsezko ezagutza eta gaitasun guztiak kanpoko erakunde baten alde zeuden.
Sistemaren garapena ia hutsetik menperatzen hasi ginen, bere ezaugarriak eta banaketa baxua kontuan hartuta. 2018ko urrian hasi zen:
- Kode sortzearen dokumentazioa eta oinarriak aztertu ditu;
- Saltzailetik jasotako garapenari buruzko ikastaro laburra aztertu dugu;
- Hasierako garapen-trebetasunak menderatzea;
- Taldekide berrientzako prestakuntza eskuliburua osatu genuen;
- Taldea βborrokaβ moduan sartzea adostu genuen;
- Kodearen kalitate-kontrolarekin arazoa konpondu da;
- Garapenerako stand bat antolatu genuen.
Hiru hilabete eman genituen espezializazioa garatzen eta sisteman murgiltzen, eta 2019aren hasieratik, barneko garapenak etorkizun distiratsurantz bere mugimendua hasi zuen, batzuetan zailtasunez, baina konfiantzaz eta nahita.
Biltegiaren migrazioa eta autotestak
DevOps lehen zeregina biltegia da. Azkar adostu genuen sarbidea ematea, baina beharrezkoa izan zen egungo SVNtik enbor adar batekin migratu gure xede Git-era, hainbat adarren eredu batera igaroz eta Git Flow-en garapenarekin. Gainera, azpiegitura propioa duten 2 talde ditugu, baita atzerrian saltzailearen taldearen zati bat ere. Bi Gitekin bizi behar izan nuen eta sinkronizazioa ziurtatu. Horrelako egoera batean, bi gaitzetatik txikiena zen.
Biltegiaren migrazioa behin eta berriz atzeratu zen;apirilean bakarrik amaitu zen, lehen lerroko lankideen laguntzarekin. Git Flow-ekin, hasiera batean gauzak sinpleak mantentzea erabaki genuen eta eskema klasikoan finkatu ginen konponketa, garatzea eta kaleratzearekin. Maisua (aka prod-like) uztea erabaki zuten. Jarraian, aukera hau guretzat egokiena zergatik izan den azalduko dugu. Saltzaileari dagokion kanpoko biltegi bat erabili zen, bi talderentzat ohikoa, langile gisa. Barne-biltegiarekin sinkronizatu zen ordutegi baten arabera. Orain Git eta Gitlab-ekin prozesuak automatizatzea posible zen.
Autotesten arazoa harrigarriro erraz konpondu zen - prest egindako marko bat eskaini ziguten. Sistemaren berezitasunak kontuan hartuta, eragiketa bereizi bat deitzea negozio-prozesuaren zati ulergarria zen eta, aldi berean, unitate-test gisa balio zuen. Proba datuak prestatzea eta scriptak deitzeko eta emaitzak ebaluatzeko nahi den ordena ezartzea besterik ez zen falta. Eragiketa-estatistiketan, prozesuen kritikotasunean eta dagoen erregresio-metodologian oinarrituta osaturiko eszenatokien zerrenda bete ahala, proba automatikoak agertzen hasi ziren. Orain kanalizazioa eraikitzen has gintezke.
Nola zen: automatizazio aurreko eredua
Inplementazio prozesuaren eredua istorio bereizia da. Aldaketa bakoitza eskuz transferitu zen instalazio inkrementaleko pakete bereizi gisa. Jarraian, Jiran eskuz erregistratzea eta inguruneetan eskuz instalatzea etorri ziren. Banakako paketeetarako, dena argi ikusten zen, baina oharra prestatzearekin batera, gauzak konplikatuagoak ziren.
Muntaia banakako bidalketen mailan egiten zen, objektu independenteak zirenak. Edozein aldaketa entrega berria da. Besteak beste, 60-70 bertsio tekniko gehitu zitzaizkien kaleratze-konposizio nagusiaren 10-15 paketeei; bertsioak kaleratzetik zerbait gehitzean edo baztertzean lortutako bertsioak eta salmenten aldaketak kaleratzeetatik kanpokoak islatuz.
Bidalketen barruko objektuak elkarren artean gainjartzen ziren, batez ere kode exekutagarrian, bakarra erdia baino gutxiago zena. Mendekotasun asko zeuden bai lehendik instalatutako kodearekin eta baita instalatu berri denarekin ere.
Kodearen behar den bertsioa lortzeko, beharrezkoa zen instalazio-ordena zorrozki jarraitu, zeinetan objektuak fisikoki berridatzi ziren askotan, 10-12 aldiz.
Pakete sorta bat instalatu ondoren, eskuz jarraitu behar izan ditut ezarpenak hasieratzeko argibideak. Oharra saltzaileak muntatu eta instalatu zuen. Argitalpenaren osaera ia inplementatzeko unea baino lehen argitu zen, eta horrek "desacoplamendu" paketeak sortzea ekarri zuen. Ondorioz, horniduraren zati esanguratsu bat kaleratzetik kaleratzera joan zen bere "desacoplamenduen" isatsarekin.
Orain argi dago ikuspegi honekin - kaleratze puzzlea pakete mailan muntatzea - ββmaisu adar bakar batek ez zuela esanahi praktikorik. Ekoizpenean instalatzeko eskulan ordu bat eta erdi eta bi bitartekoa izan behar zen. Ona da instalatzaile mailan gutxienez objektuen prozesamenduaren ordena zehaztea: eremuak eta egiturak haien datuak eta prozeduren aurretik sartu ziren. Hala ere, honek pakete berezi batean bakarrik funtzionatu zuen.
Ikuspegi honen emaitza logikoa derrigorrezko instalazio akatsak izan ziren: objektuen bertsio makurrak, alferrikako kodeak, falta diren argibideak eta objektuen elkarrekiko eraginak, zeinak askatu ondoren sukarrez ezabatu zirenak.
Lehen eguneraketak: konprometitu muntaketa eta entrega
Automatizazioa bide honetan zehar hodi baten bidez kodea transmititzen hasi zen:
- Jaso amaitutako entrega biltegitik;
- Instalatu ingurune dedikatu batean;
- Exekutatu autotestak;
- Instalazioaren emaitza ebaluatu;
- Deitu proba komandoaren alboko hurrengo kanalera.
Hurrengo kanalizazioak zeregina Jira-n erregistratu beharko luke eta aginduak hautatutako proba-begiztetan banatzen diren arte itxaron beharko luke, eta horiek zereginaren ezarpenaren denboraren araberakoak izango dira. Trigger - helbide jakin batera bidaltzeko prest dagoen gutuna. Hau, noski, makulu agerikoa zen, baina nonbaitetik hasi behar nuen. 2019ko maiatzean, kodearen transferentzia gure inguruneen egiaztapenekin hasi zen. Prozesua hasi da, nahikoa da forma duin batean jartzea:
- Aldaketa bakoitza adar bereizi batean egiten da, instalazio paketeari dagokiona eta helburuko adar nagusiarekin bat egiten duena;
- Pipeline abiarazte-abiarazlea adar maisuan konpromezu berri bat agertzea da, bateratze-eskaera baten bidez, etxeko taldeko mantentzaileek ixten dutena;
- Biltegiak bost minuturo behin sinkronizatzen dira;
- Instalazio paketearen muntaketa hasten da - saltzaileak jasotako muntatzailea erabiliz.
Honen ostean, jada existitzen ziren urratsak kodea egiaztatu eta transferitzeko, kanalizazioa abiarazteko eta gure alde muntatzeko.
Aukera hau uztailean jarri zen martxan. Trantsizioaren zailtasunek nolabaiteko atsekabea eragin zuten saltzailearen eta lehen lerroaren artean, baina hurrengo hilabetean ertz zakar guztiak kentzea eta taldeen artean prozesu bat ezartzea lortu genuen. Orain konpromisoz eta entregaz muntatzea dugu.
Abuztuan, gure kanalizazioa erabiliz produkzioan aparteko pakete baten lehen instalazioa amaitzea lortu genuen, eta irailetik aurrera, salbuespenik gabe, kaleratu gabeko pakete indibidualen instalazio guztiak gure CD tresnaren bidez egin ziren. Horrez gain, kaleratze-konposizioaren %40an barne-zereginen zati bat lortzea lortu genuen saltzaileak baino talde txikiagoarekin - hau behin betiko arrakasta da. Zeregin larriena geratzen zen: oharra muntatzea eta instalatzea.
Azken irtenbidea: instalazio-pakete pilatuak
Primeran ulertu genuen saltzailearen argibideak idaztea horrenbesteko automatizazioa zela; prozesua bera birplanteatu behar izan genuen. Irtenbidea begien bistakoa zen: behar diren bertsioen objektu guztiekin kaleratze adarreko hornidura metatua biltzea.
Kontzeptuaren frogarekin hasi ginen: eskuz muntatu genuen kaleratze paketea iraganeko inplementazioaren edukiaren arabera eta gure inguruneetan instalatu genuen. Dena atera zen, kontzeptua bideragarria izan zen. Ondoren, hasierako ezarpenak scripting-en eta konpromisoan sartzeko arazoa konpondu genuen. Pakete berri bat prestatu genuen eta proba-inguruneetan probatu genuen sestra eguneratzearen zati gisa. Instalazioa arrakastatsua izan zen, nahiz eta ezarpen-taldearen iruzkin sorta zabalarekin. Baina gauza nagusia da gure muntaiarekin azaroko argitalpenean produkzioan sartzeko baimena eman zigula.
Hilabete pasatxo falta zenean, eskuz jasotako hornigaiek argi eta garbi adierazten zuten denbora agortzen ari zela. Askapenaren adarretik eraikitzea erabaki zuten, baina zergatik bereizi behar da? Ez dugu Prod antzekorik, eta lehendik dauden adarrak ez dira onak - alferrikako kode asko dago. Premiazkoa dugu prod-likeak moztu, eta hiru mila konpromiso baino gehiago dira. Eskuz muntatzea ez da batere aukera bat. Produktuaren instalazioaren erregistroan zehar exekutatzen den eta adarrarekiko konpromisoak biltzen dituen script bat zirriborratu dugu. Hirugarren aldian ondo funtzionatu zuen, eta "fitxategi batekin amaitu" ondoren adarra prest zegoen.
Instalazio paketerako gure eraikitzailea idatzi genuen eta aste batean amaitu genuen. Ondoren, instalatzailea aldatu behar izan dugu sistemaren oinarrizko funtzionalitatetik, kode irekikoa baita. Egiaztapen eta aldaketa batzuen ondoren, emaitza arrakastatsutzat jo zen. Bitartean, argitalpenaren osaera itxura hartu zuen, zeinaren instalazio zuzena egiteko beharrezkoa zen proba-zirkuitua ekoizpenarekin lerrokatzea, eta horretarako gidoi bereizia idatzi zen.
Jakina, iruzkin asko egon ziren lehenengo instalazioari buruz, baina, oro har, kodeak funtzionatu zuen. Eta hirugarren instalazioaren ondoren, dena ondo ikusten hasi zen. Objektuen konposizio-kontrola eta bertsio-kontrola banan-banan kontrolatu ziren eskuzko moduan, fase honetan nahiko justifikatua zegoen.
Erronka gehigarria izan zen kontuan hartu behar ziren kaleratze ez-kopuru handia. Baina Prod-like adarrarekin eta Rebaserekin, zeregina garden bihurtu zen.
Lehen aldia, azkar eta akatsik gabe
Jarrera baikorrarekin eta zirkuitu ezberdinetan dozena bat instalazio arrakastatsu baino gehiagorekin heldu gara estreinaldira. Baina, literalki, epea amaitu baino egun bat lehenago, saltzaileak ez zuela amaitu oharra instalatzeko modu onartuan prestatzeko lanak. Arrazoiren batengatik gure eraikuntzak funtzionatzen ez badu, oharra eten egingo da. Gainera, gure ahaleginen bidez, eta hori bereziki desatsegina da. Ez genuen atzera egiteko modurik. Hori dela eta, aukera alternatiboak pentsatu, ekintza planak prestatu eta instalazioari ekin genion.
Harrigarria bada ere, kaleratze osoa, 800 objektu baino gehiagoz osatua, behar bezala hasi zen lehen aldiz eta 10 minutu besterik ez. Ordubete eman genuen erregistroak akatsen bila aztertzen, baina ez genuen aurkitu.
Hurrengo egun osoan isiltasuna egon zen kaleratze txatean: inplementazio arazorik ez, bertsio okerrik edo kode "desegokia". Nolabait deserosoa ere izan zen. Geroago, iruzkin batzuk agertu ziren, baina beste sistema batzuekin eta aurreko esperientziarekin alderatuta, haien kopurua eta lehentasuna nabarmen txikiagoak ziren.
Efektu metatuaren efektu gehigarri bat muntaketaren eta proben kalitatearen igoera izan zen. Oharra osoko hainbat instalazio direla eta, eraikuntza-akatsak eta inplementazio-akatsak garaiz identifikatu ziren. Askapen osoko konfigurazioetan egindako probak, instalazio inkrementaletan agertzen ez ziren objektuen elkarrekiko eraginaren akatsak identifikatzea ahalbidetu zuen. Zalantzarik gabe, arrakastatsua izan zen, batez ere oharra egiteko %57ko ekarpena ikusita.
Emaitzak eta ondorioak
Urtebete baino gutxiagoan lortu genuen:
- Eraiki barne garapen osoa sistema exotiko bat erabiliz;
- Ezabatu saltzaileen menpekotasun kritikoa;
- Abiarazi CI/CD oso lagunarteko ondare baterako;
- Ezarpen-prozesuak maila tekniko berri batera igo;
- Inplementazio denbora nabarmen murriztea;
- Ezarpen-akatsen kopurua nabarmen murriztea;
- Ziurtasunez deklaratu zure burua garapenerako aditu nagusi gisa.
Jakina, deskribatzen denaren zati handi batek hutsalkeria dirudi, baina hauek dira sistemaren ezaugarriak eta bertan dauden prozesuen mugak. Une honetan, aldaketek IS Profileko produktu eta zerbitzuei eragin diete (kontu nagusiak, plastikozko txartelak, aurrezki kontuak, fideikomisoak, diru-maileguak), baina potentzialki ikuspegia DevOps praktikak ezartzeko zeregina ezarrita dagoen edozein IStan aplika daiteke. Eredu metatua modu seguruan errepikatu daiteke bidalketa askoren ondorengo inplementazioetarako (argitaratze gabekoak barne).
Iturria: www.habr.com