Orain DevOps-en gaia hype dago. Etengabeko integrazioa eta entrega-lerroa denek ezartzen dute. Baina gehienek ez diote beti behar bezalako arreta jartzen CI/CD Pipelineko hainbat fasetan informazio sistemen fidagarritasuna bermatzeari. Artikulu honetan softwarearen kalitatearen egiaztapenak automatizatzeko eta bere "autosendatzeko" eszenatoki posibleak ezartzeko nire esperientziari buruz hitz egin nahiko nuke.
Enpresa bateko IT zerbitzuen kudeaketa sailean ingeniari gisa lan egiten dut . Nire oinarrizko espezializazioa aplikazioen errendimendua eta erabilgarritasuna kontrolatzeko sistema ezberdinen ezarpena da. Sarritan komunikatzen naiz merkatu-segmentu ezberdinetako IT bezeroekin beren IT zerbitzuen kalitatearen jarraipenari buruzko egungo gaiei buruz. Helburu nagusia kaleratze-zikloaren denbora gutxitzea eta askapenen maiztasuna handitzea da. Hau, noski, ona da: bertsio gehiago - funtzio berri gehiago - erabiltzaile pozik - irabazi gehiago. Baina, egia esan, gauzak ez dira beti ondo ateratzen. Inplementazio-tasa oso altuak izanik, berehala sortzen da galdera gure bertsioen kalitateari buruz. Nahiz eta kanalizazio guztiz automatizatua izan, erronka handienetako bat zerbitzuak probatik produkziora pasatzea da, aplikazioen funtzionamendu-denboran eta erabiltzailearen esperientzian eragin gabe.
Bezeroekin izandako elkarrizketa ugariren emaitzetan oinarrituta, esan dezaket askatu egiten direla kalitate-kontrola, aplikazioaren fidagarritasunaren arazoa eta bere "auto-sendatzeko" aukera (adibidez, bertsio egonkor batera itzultzea) CIren hainbat fasetan. /CD pipeline gai zirraragarri eta garrantzitsuenen artean daude.
Duela gutxi, nik neuk bezeroaren alde lan egin nuen - lineako banku aplikazioaren softwarearen laguntza zerbitzuan. Gure aplikazioaren arkitekturak auto-idatzitako mikrozerbitzu ugari erabili zituen. Tristeena da garatzaile guztiek ezin izan ziotela aurre egin garapen-erritmo handiari; mikrozerbitzu batzuen kalitatea jasan zuten, eta horrek ezizen dibertigarriak sortu zizkieten haientzat eta haien sortzaileentzat. Produktu horiek zein materialez egin ziren buruzko istorioak zeuden.
"Arazoaren formulazioa"
Argitalpenen maiztasun altuak eta mikrozerbitzu ugariak zaildu egiten du aplikazioaren funtzionamendua bere osotasunean ulertzea, bai proba fasean, bai fase operatiboan. Aldaketak etengabe gertatzen dira eta oso zaila da kontrolatzea monitorizazio tresna onak gabe. Askotan, goizean gaueko kaleratu ondoren, garatzaileak hauts-kupel batean bezala esertzen dira eta ezer apurtu arte itxaroten dute, proba-fasean egiaztapen guztiak arrakastatsuak izan arren.
Puntu bat gehiago dago. Proba fasean, softwarearen funtzionaltasuna egiaztatzen da: aplikazioaren funtzio nagusien ezarpena eta akatsik eza. Errendimendu kualitatiboen ebaluazioak falta dira edo ez dituzte aplikazioaren eta integrazio-geruzaren alderdi guztiak kontuan hartzen. Baliteke neurri batzuk ez egiaztatzea. Ondorioz, produkzio-ingurune batean matxura bat gertatzen denean, laguntza teknikoko sailak benetako erabiltzaileak kexatzen hasten direnean bakarrik jakingo du. Kalitate baxuko softwareak azken erabiltzaileengan duen eragina minimizatu nahiko nuke.
Irtenbideetako bat da softwarearen kalitatea egiaztatzeko prozesuak ezartzea CI/CD Pipelineko hainbat fasetan, eta larrialdi-egoeran sistema berreskuratzeko hainbat eszenatoki gehitzea. DevOps dugula ere gogoratzen dugu. Enpresek produktu berri bat ahalik eta azkarren jasotzea espero dute. Beraz, gure egiaztapen eta script guztiak automatizatu behar dira.
Eginkizuna bi osagaitan banatzen da:
- muntaien kalitate-kontrola proba-fasean (kalitate baxuko muntaiak harrapatzeko prozesua automatizatzeko);
- softwarearen kalitate-kontrola ekoizpen-ingurunean (arazoak automatikoki detektatzeko mekanismoak eta haien autosendatzeko eszenatoki posibleak).
Neurketak kontrolatzeko eta biltzeko tresna
Ezarritako helburuak lortzeko, arazoak hauteman eta automatizazio-sistemetara transferituko dituen monitorizazio-sistema behar da, CI/CD kanalizazioaren hainbat fasetan. Era berean, gauza positiboa izango da sistema honek hainbat talderentzat neurri baliagarriak eskaintzen baditu: garapena, probak, funtzionamendua. Eta guztiz zoragarria da negozioetarako ere bada.
Metrikoak biltzeko, sistema ezberdinen multzo bat erabil dezakezu (Prometheus, ELK Stack, Zabbix, etab.), baina, nire ustez, APM mailako soluzioak dira zeregin horietarako egokienak (), eta horrek asko erraztu dezake zure bizitza.
Laguntza-zerbitzuan dudan lanaren barruan, Dynatrace-ko APM klaseko soluzio bat erabiliz antzeko proiektu bat egiten hasi nintzen. Orain, integratzaile batean lanean, ondo ezagutzen dut monitorizazio sistemen merkatua. Nire iritzi subjektiboa: Dynatrace da egokiena horrelako arazoak konpontzeko.
Dynatrace-k erabiltzailearen eragiketa bakoitzaren ikuspegi horizontala eskaintzen du maila xehean, kodearen exekuzio mailaraino. Hainbat informazio-zerbitzuren arteko interakzio-kate osoa jarraipena egin dezakezu: web eta mugikorreko aplikazioen frontend-mailetatik hasita, aplikazio-zerbitzariak back-end, integrazio-busa datu-baserako dei zehatz bateraino.
. Sistemaren osagaien arteko mendekotasun guztien eraikuntza automatikoa
. Zerbitzuaren funtzionamendu-bidea automatikoki hautematea eta eraikitzea
Gainera, gogoan dugu hainbat automatizazio tresnarekin integratu behar dugula. Hemen irtenbideak API eroso bat du, hainbat metrika eta gertaera bidali eta jasotzeko aukera ematen duena.
Jarraian, joan gaitezen arazo hauek Dynatrace sistema erabiliz nola konpondu aztertzen.
1. zeregina. Entsegu fasean muntaien kalitate-kontrola automatizatzea
Lehenengo erronka aplikazioen entrega-bidean arazoak ahalik eta azkarren aurkitzea da. Kode "onak" eraikitzek soilik iritsi beharko lukete ekoizpenera. Horretarako, proba-fasean zure kanalizazioak monitore osagarriak izan beharko lituzke zure zerbitzuen kalitatea egiaztatzeko.
Ikus dezagun urratsez urrats hau nola inplementatu eta prozesu hau automatizatu:
Irudiak software automatizatuaren kalitatearen probaren urratsen fluxua erakusten du:
- jarraipen-sistema bat ezartzea (agenteen instalazioa);
- zure softwarearen kalitatea ebaluatzeko gertaerak identifikatzea (neurriak eta atalase-balioak) eta monitorizazio-sistemara transferitzea;
- karga eta errendimendu probak sortzea;
- jarraipen-sisteman errendimendu- eta erabilgarritasun-datuak biltzea;
- Softwarearen kalitatea ebaluatzeko gertaeretan oinarritutako proba-datuak monitorizazio-sistematik CI/CD sistemara transferitzea. Muntaien azterketa automatikoa.
1. urratsa. Jarraipen-sistemaren hedapena
Lehenik eta behin agenteak zure proba-ingurunean instalatu behar dituzu. Aldi berean, Dynatrace irtenbideak ezaugarri polita du: OneAgent agente unibertsala erabiltzen du, zeina OS instantzia batean (Windows, Linux, AIX) instalatuta dagoena, zure zerbitzuak automatikoki detektatzen ditu eta haien gaineko monitorizazio datuak biltzen hasten da. Ez duzu prozesu bakoitzeko agente bereizirik konfiguratu beharrik. Egoera antzekoa izango da hodeiko eta edukiontzien plataformetan. Aldi berean, agentea instalatzeko prozesua automatiza dezakezu. Dynatrace ezin hobeto egokitzen da "azpiegitura kode gisa" kontzeptuan (): Prestatutako gidoiak eta argibideak daude plataforma ezagun guztietarako. Agentea zure zerbitzuaren konfigurazioan txertatzen duzu, eta zabaltzen duzunean, berehala jasotzen duzu zerbitzu berri bat dagoeneko lanean ari den agente batekin.
2. urratsa: Definitu zure softwarearen kalitate-gertaerak
Orain zerbitzuen eta negozio-eragiketen zerrenda erabaki behar duzu. Garrantzitsua da zure zerbitzurako negozio kritikoak diren erabiltzaileen eragiketak zehatz-mehatz kontuan hartzea. Hemen negozio eta sistemen analistarekin kontsultatzea gomendatzen dut.
Ondoren, maila bakoitzeko berrikuspenean zein neurri sartu nahi dituzun zehaztu behar duzu. Esaterako, hau izan daiteke exekuzio denbora (batez bestekoa, mediana, pertzentiletan, etab. banatuta), erroreak (logikoak, zerbitzua, azpiegiturak, etab.) eta hainbat azpiegitura-neurri (memoria pila, zabor-biltzailea, hari kopurua, etab.).
DevOps taldeak automatizatzeko eta erabiltzeko erraztasuna lortzeko, "Kode gisa monitorizatzea" kontzeptua agertzen da. Honekin esan nahi dudana da garatzaile/probatzaile batek JSON fitxategi sinple bat idatz dezakeela, softwarearen kalitatea bermatzeko neurriak definitzen dituena.
Ikus dezagun JSON fitxategi baten adibide bat. Dynatrace APIko objektuak gako/balio pare gisa erabiltzen dira (APIaren deskribapena hemen aurki daiteke ).
{
"timeseries": [
{
"timeseriesId": "service.ResponseTime",
"aggregation": "avg",
"tags": "Frontend",
"severe": 250000,
"warning": 1000000
},
{
"timeseriesId": "service.ResponseTime ",
"aggregation": "avg",
"tags": "Backend",
"severe": 4000000,
"warning": 8000000
},
{
"timeseriesId": "docker.Container.Cpu",
"aggregation": "avg",
"severe": 50,
"warning": 70
}
]
}Fitxategia denbora serieen definizio sorta bat da:
- timeseriesId – egiaztatzen ari den metrika, adibidez, Erantzun Denbora, Errore kopurua, Erabilitako memoria, etab.;
- agregazioa - metrika agregazio maila, gure kasuan batez bestekoa, baina behar duzun edozein erabil dezakezu (batez bestekoa, min., gehienez, batura, zenbaketa, pertzentilea);
- tags - objektuaren etiketa jarraipen-sisteman, edo objektu-identifikatzaile zehatz bat zehaztu dezakezu;
- larria eta abisua - adierazle hauek gure neurketen atalase-balioak arautzen dituzte; proba-balioak atalase larria gainditzen badu, gure eraikuntza arrakastatsu gisa markatuta dago.
Hurrengo irudian atalase horien erabileraren adibide bat erakusten da.
3. urratsa: Karga sortzea
Gure zerbitzuaren kalitate-mailak zehaztu ondoren, proba-karga bat sortu behar dugu. Eroso zauden proba-tresnetako edozein erabil dezakezu, hala nola Jmeter, Selenium, Neotys, Gatling, etab.
Dynatrace-ren jarraipen-sistemak zure probetako hainbat metadatu harrapatzeko eta zein probak zein kaleratze-ziklotakoak eta zein zerbitzutakoak diren ezagutzeko aukera ematen dizu. Gomendatzen da goiburu gehigarriak gehitzea HTTP proba-eskaerei.
Hurrengo irudiak adibide bat erakusten du, non, X-Dynatrace-Test goiburu gehigarria erabiliz, proba hau gurdiari elementu bat gehitzeko eragiketa probatzeari dagokiola adierazten dugun.
Karga-proba bakoitza exekutatzen duzunean, testuinguruko informazio gehigarria bidaltzen diozu Dynatrace-ri Gertaera APIa erabiliz, CI/CD zerbitzaritik. Horrela, sistemak proba desberdinak bereiz ditzake.
. Karga-probaren hasierari buruzko jarraipen-sisteman gertaera
4-5 urratsa. Bildu errendimendu-datuak eta transferitu datuak CI/CD sistemara
Sortutako probarekin batera, zerbitzuaren kalitate-adierazleak egiaztatzeko datuak biltzeko beharrari buruzko gertaera bat igortzen da jarraipen-sistemara. Gainera, gure JSON fitxategia zehazten du, gako-neurriak definitzen dituena.
Monitorizazio sistemara bidaltzeko CI/CD zerbitzarian sortutako softwarearen kalitatea egiaztatu beharrari buruzko ekitaldia
Gure adibidean, kalitatea egiaztatzeko gertaera deitzen da perfSigDynatraceReport (Errendimendua_Sinadura) - hau prest dago Jenkins-ekin integratzeko, T-Systems Multimedia Solutions-eko mutilek garatu zutena. Proba abiarazteko gertaera bakoitzak zerbitzuari, eraikuntza-zenbakiari eta proba-denborari buruzko informazioa dauka. Pluginak errendimendu-balioak biltzen ditu eraikitze-unean, ebaluatzen ditu eta emaitza aurreko eraikuntzarekin eta ez-funtzionalekin alderatzen du.
Eraikuntzaren kalitatearen egiaztapenaren hasierari buruzko monitorizazio sisteman gertaera.
Proba amaitu ondoren, softwarearen kalitatea ebaluatzeko neurketa guztiak etengabeko integrazio sistema batera transferitzen dira, adibidez, Jenkins, emaitzei buruzko txostena sortzen duena.
CI/CD zerbitzariko muntaien estatistiken emaitza.
Eraikuntza bakoitzerako, proba osoan ezarri dugun metrika bakoitzaren estatistikak ikusten ditugu. Era berean, atalase-balio jakin batzuetan urraketak egon diren ikusten dugu (abisua eta thrashhold larriak). Neurri agregatuetan oinarrituta, eraikuntza osoa egonkor, ezegonkor edo huts gisa markatzen da. Gainera, erosotasunerako, txostenean adierazleak gehi ditzakezu egungo eraikuntza aurrekoarekin alderatuz.
Ikusi CI/CD zerbitzarian muntaketen estatistika zehatzak.
Bi multzoen konparaketa zehatza
Beharrezkoa izanez gero, Dynatrace interfazera joan zaitezke eta bertan zure eraikuntza bakoitzaren estatistikak xehetasun gehiagoz ikusi eta elkarren artean konparatu ditzakezu.
Dynatrace-n eraikitze-estatistiken konparaketa.
Findings
Ondorioz, “monitorizazio zerbitzu gisa” zerbitzu bat lortzen dugu, etengabeko integrazio-bidean automatizatua. Garatzaileak edo probatzaileak JSON fitxategi batean metrika zerrenda bat definitu behar du soilik, eta gainerako guztia automatikoki gertatzen da. Argitalpenen kalitate-kontrol gardena jasotzen dugu: errendimenduari, baliabideen kontsumoari edo erregresio arkitektonikoei buruzko jakinarazpen guztiak.
2. ataza. Produkzio-ingurunean softwarearen kalitate-kontrola automatizatzea
Beraz, Pipelineko proba-fasean monitorizazio-prozesua nola automatizatzeko arazoa konpondu dugu. Horrela, ekoizpen-ingurunera iristen diren kalitate baxuko muntaien ehunekoa minimizatzen dugu.
Baina zer egin software txarra saltzen bada, edo zerbait hautsi besterik ez bada. Utopia baterako, arazoak automatikoki detektatzeko mekanismoak nahi genituen eta, ahal izanez gero, sistemak berak bere funtzionaltasuna berreskuratzeko, gauez behintzat.
Horretarako, aurreko atalaren analogiaz, produkzio-ingurunean softwarearen kalitatearen egiaztapen automatikoak eskaintzea eta sistemaren autosendatzeko agertokietan oinarritzea behar dugu.
Kode gisa automatikoki zuzendu
Enpresa gehienek dagoeneko pilatuta daukate hainbat motatako arazo arrunten ezagutza-base bat eta horiek konpontzeko ekintzen zerrenda bat, adibidez, prozesuak berrabiaraztea, baliabideak garbitzea, bertsioak atzera botatzea, konfigurazio-aldaketa baliogabeak berreskuratzea, osagai kopurua handitzea edo txikitzea. klusterra, eskema urdina edo berdea aldatuz etab.
Hitz egiten ditudan talde askok erabilera-kasu hauek urteak daramatzaten arren, gutxik pentsatu edo inbertitu dute horiek automatizatzeko.
Pentsatzen baduzu, ez dago ezer konplikatuegirik auto-sendatzeko aplikazioen errendimendurako prozesuak ezartzean; dagoeneko ezagutzen diren zure administratzaileen lan-eszenatokiak kode-scripten moduan aurkeztu behar dituzu ("auto-konponketa kode gisa" kontzeptua) , kasu zehatz bakoitzerako aldez aurretik idatzi duzuna. Konponketa automatikoko scriptek arazoaren jatorria ezabatzera zuzenduta egon behar dute. Zuk zeuk zehazten duzu gertakari bati erantzuteko ekintza zuzenak.
Zure monitorizazio-sistemako edozein metrika gidoia abiarazteko abiarazle gisa jardutea da, gauza nagusia da metrika horiek zehaztasunez zehazten dutela dena txarra dela, ez baitzuzu positibo faltsurik lortu nahi ingurune produktibo batean.
Edozein sistema edo sistema multzo erabil dezakezu: Prometheus, ELK Stack, Zabbix, etab. Baina APM soluzio batean oinarritutako adibide batzuk emango ditut (Dynatrace berriro adibide bat izango da) zure bizitza errazten lagunduko dizutenak ere.
Lehenik eta behin, errendimenduarekin lotutako guztia dago aplikazioaren funtzionamenduari dagokionez. Irtenbideak ehunka neurketa eskaintzen ditu hainbat mailatan, abiarazle gisa erabil ditzakezun:
- erabiltzaile-maila (arakatzaileak, aplikazio mugikorrak, IoT gailuak, erabiltzailearen portaera, bihurketa, etab.);
- zerbitzu eta eragiketa maila (errendimendua, erabilgarritasuna, akatsak, etab.);
- aplikazioen azpiegitura maila (ostalariaren OS neurketak, JMX, MQ, web-zerbitzaria, etab.);
- plataforma maila (birtualizazioa, hodeia, edukiontzia, etab.).
Monitorizazio mailak Dynatrace-n.
Bigarrenik, lehen esan dudan bezala, Dynatrace-k API irekia du, eta horrek oso erraza da hirugarrenen sistema ezberdinekin integratzea. Adibidez, kontrol-parametroak gainditzen direnean automatizazio-sistemari jakinarazpena bidaltzea.
Jarraian, Ansible-rekin elkarreragiteko adibide bat dago.
Jarraian, nolako automatizazioa egin daitekeen adibide batzuk emango ditut. Hau kasuen zati bat besterik ez da; zure ingurunean duten zerrenda zure irudimenak eta zure monitorizazio tresnen gaitasunek soilik mugatu dezakete.
1. Inplementazio txarra - bertsioa atzera botatzea
Nahiz eta proba-ingurunean dena oso ondo probatzen badugu, aukera dago bertsio berri batek zure aplikazioa produkzio-ingurune batean hiltzeko. Giza faktore bera ez da bertan behera utzi.
Hurrengo irudian zerbitzuko eragiketen exekuzio denboran jauzi handia dagoela ikusten dugu. Jauzi honen hasiera aplikazioan hedatzeko unearekin bat dator. Informazio hori guztia gertakari gisa transmititzen dugu automatizazio sistemara. Ezarritako denboraren ondoren zerbitzuaren errendimendua normaltasunera itzultzen ez bada, orduan automatikoki deitzen da bertsioa zaharrera itzultzen duen script bat.
Eragiketen errendimendua hondatzea zabaldu ondoren.
2. Baliabideen karga % 100ean - gehitu nodo bat bideraketari
Hurrengo adibidean, monitorizazio-sistemak zehazten du osagaietako batek %100eko CPU karga jasaten duela.
CPU karga % 100
Gertaera honetarako hainbat eszenatoki posible daude. Esaterako, monitorizazio-sistemak baliabide falta zerbitzuaren karga handitzearekin lotzen den egiaztatzen du. Hala bada, bideraketari automatikoki nodo bat gehitzen dion script bat exekutatuko da, eta horrela sistema osoaren funtzionaltasuna berreskuratzen du.
Gorabehera baten ondoren eskalatzea
3. Disko gogorrean leku falta - disko garbiketa
Uste dut jende askok dagoeneko automatizatu dituela prozesu hauek. APM erabiliz, disko azpisistemako espazio librea ere kontrola dezakezu. Lekurik ez badago edo diskoa poliki exekutatzen ari bada, script bati deitzen diogu garbitzeko edo espazioa gehitzeko.
Diskoaren karga % 100
4. Erabiltzaileen jarduera txikia edo bihurketa txikia - adar urdin eta berdeen artean aldatzea
Askotan ikusten ditut bezeroak bi begizta (inplementatze urdin-berdea) erabiltzen dituzten aplikazioetarako. Horri esker, adar batetik bestera azkar alda dezakezu bertsio berriak entregatzerakoan. Askotan, zabaldu ondoren, berehala nabaritzen ez diren aldaketa ikaragarriak gerta daitezke. Kasu honetan, baliteke errendimenduaren eta erabilgarritasunaren degradazioa ez ikustea. Aldaketei azkar erantzuteko, hobe da erabiltzailearen portaera islatzen duten hainbat neurketa erabiltzea (saio eta erabiltzailearen ekintza kopurua, bihurketa, errebote-tasa). Hurrengo irudiak adibide bat erakusten du, non, bihurketa-tasak jaisten direnean, software-adar batetik bestera aldatzea gertatzen den.
Bihurketa-tasa jaisten da software-adar batetik bestera aldatu ondoren.
Arazoak automatikoki hautemateko mekanismoak
Azkenik, Dynatrace gehien gustatzen zaidalako adibide bat emango dizut.
Test-ingurunean muntaien kalitate-egiaztapenak automatizatzeari buruzko nire istorioaren zatian, atalase-balio guztiak eskuz zehaztu ditugu. Hau normala da proba-ingurune baterako; probatzaileak berak zehazten ditu adierazleak proba bakoitzaren aurretik, kargaren arabera. Ekoizpen-ingurunean, komeni da arazoak automatikoki detektatzea, oinarrizko hainbat mekanismo kontuan hartuta.
Dynatrace-k adimen artifizialeko tresna interesgarriak ditu barneratuta, metrika anomaliak (baselining) zehazteko eta osagai guztien arteko interakzio mapa eraikitzeko mekanismoetan oinarrituta, gertaerak elkarren artean alderatuz eta erlazionatuz, zure zerbitzuaren funtzionamenduan anomaliak zehazten dituzten eta xehetasun zehatzak eskaintzen dituztenak. arazo eta arrazoi bakoitzari buruzko informazioa.
Osagaien arteko mendekotasunak automatikoki aztertuz, Dynatrace-k zerbitzu problematikoa arrazoi nagusia den ez ezik, beste zerbitzuekiko duen menpekotasuna ere zehazten du. Beheko adibidean, Dynatrace-k automatikoki kontrolatzen eta ebaluatzen du zerbitzu bakoitzaren osasuna transakzio exekuzioaren barruan, Golang zerbitzua erroko kausa gisa identifikatuz.
Hutsegite baten jatorria zehazteko adibide bat.
Ondorengo irudiak zure aplikazioaren arazoak gainbegiratzeko prozesua intzidentziaren hasieratik erakusten du.
Sortzen ari den arazo baten bistaratzea, osagai eta gertakari guztiak erakusteko
Jarraipen-sistemak sortutako arazoarekin lotutako gertaeren kronologia osoa bildu zuen. Denbora-lerroaren azpiko leihoan osagai bakoitzaren funtsezko gertaera guztiak ikusiko ditugu. Gertaera horietan oinarrituta, zuzenketa automatikorako prozedurak ezar ditzakezu kode-scripten moduan.
Gainera, jarraipen-sistema bat Service Desk-ekin edo akatsen jarraitzaile batekin integratzea gomendatzen dizut. Arazo bat gertatzen denean, garatzaileek azkar jasotzen dute informazio osoa ekoizpen-ingurunean kode mailan aztertzeko.
Ondorioa
Ondorioz, Pipeline-n software automatikoen kalitate-kontrol automatizatuak dituen CI/CD kanalizazio batekin amaitu genuen. Kalitate baxuko muntaien kopurua gutxitzen dugu, sistema osoaren fidagarritasuna areagotzen dugu eta gure sistemak oraindik huts egiten badu, leheneratzeko mekanismoak abiarazten ditugu.
Zalantzarik gabe, merezi du ahaleginak inbertitzea softwarearen kalitatearen monitorizazioa automatizatzeko; ez da beti prozesu azkarra, baina denborarekin fruituak emango ditu. Gomendatzen dut ekoizpen-ingurunean gorabehera berri bat konpondu ondoren, berehala pentsatzea proba-ingurunean egiaztapenetarako zein monitor gehitu behar dituzun, eraikuntza txar bat produkzioan sar ez dadin, eta, gainera, arazo hauek automatikoki zuzentzeko script bat sortzea.
Espero dut nire adibideek zure ahaleginetan lagunduko zaituztela. Gainera, autosendatzeko sistemak ezartzeko erabiltzen diren metriken adibideak ikustea interesatuko zait.
Iturria: www.habr.com