Nyt DevOps-aihe on hype-tilassa. Jatkuva integrointi ja toimitusputki kaikki toteuttavat sitä. Mutta useimmat eivät aina kiinnitä riittävästi huomiota tietojärjestelmien luotettavuuden varmistamiseen CI/CD-putkilinjan eri vaiheissa. Tässä artikkelissa haluaisin puhua kokemuksestani ohjelmistojen laaduntarkistuksen automatisoimisesta ja mahdollisten skenaarioiden toteuttamisesta sen "itseparannukseen".
Työskentelen insinöörinä yrityksen IT-palveluiden hallinnassa . Ydinosaamisalueeni on erilaisten sovellusten suorituskyvyn ja saatavuuden seurantajärjestelmien toteuttaminen. Kommunikoin usein IT-asiakkaiden kanssa eri markkinasegmenteistä heidän IT-palveluidensa laadunvalvontaan liittyvistä ajankohtaisista asioista. Päätavoitteena on minimoida vapautumissyklin aika ja lisätä julkaisujen tiheyttä. Tämä on tietysti hyvä: enemmän julkaisuja - enemmän uusia ominaisuuksia - enemmän tyytyväisiä käyttäjiä - enemmän voittoa. Mutta todellisuudessa asiat eivät aina mene hyvin. Kun käyttöönottoasteet ovat erittäin korkeat, herää heti kysymys julkaisujemme laadusta. Jopa täysin automatisoidulla putkilinjalla yksi suurimmista haasteista on palvelujen siirtäminen testauksesta tuotantoon vaikuttamatta sovellusten käytettävyyteen ja käyttökokemukseen.
Asiakkaiden kanssa käytyjen lukuisten keskustelujen tulosten perusteella voin sanoa, että julkaisun laadunvalvonta, sovelluksen luotettavuusongelma ja sen "itseparantumisen" mahdollisuus (esimerkiksi palautuminen vakaaseen versioon) CI:n eri vaiheissa /CD-piippu on yksi jännittävimmistä ja oleellisimmista aiheista.
Viime aikoina olen itse työskennellyt asiakaspuolella - verkkopankkisovellusohjelmistojen tukipalvelussa. Sovelluksemme arkkitehtuuri käytti suurta määrää itse kirjoitettuja mikropalveluita. Surullisinta on, että kaikki kehittäjät eivät kestäneet nopeaa kehitysvauhtia, joidenkin mikropalvelujen laatu kärsi, mikä aiheutti hauskoja lempinimiä heille ja niiden tekijöille. Siellä kerrottiin, mistä materiaaleista nämä tuotteet on tehty.
"Ongelman muotoilu"
Suuri julkaisutiheys ja suuri määrä mikropalveluita vaikeuttavat sovelluksen toiminnan ymmärtämistä kokonaisuutena sekä testaus- että käyttövaiheessa. Muutoksia tapahtuu jatkuvasti ja niitä on erittäin vaikea hallita ilman hyviä seurantatyökaluja. Usein aamun yöjulkaisun jälkeen kehittäjät istuvat kuin ruutitynnyrin päällä ja odottavat, ettei mikään hajoa, vaikka kaikki tarkastukset onnistuivatkin testausvaiheessa.
On vielä yksi kohta. Testausvaiheessa tarkistetaan ohjelmiston toimivuus: sovelluksen päätoimintojen toteutus ja virheiden puuttuminen. Laadulliset suorituskyvyn arvioinnit joko puuttuvat tai eivät ota huomioon kaikkia sovelluksen ja integraatiokerroksen näkökohtia. Joitakin mittareita ei ehkä tarkasteta ollenkaan. Tämän seurauksena, kun tuotantoympäristössä tapahtuu vika, teknisen tuen osasto saa tiedon siitä vasta, kun todelliset käyttäjät alkavat valittaa. Haluan minimoida heikkolaatuisten ohjelmistojen vaikutuksen loppukäyttäjiin.
Yksi ratkaisuista on toteuttaa prosesseja ohjelmiston laadun tarkistamiseksi CI/CD-putkilinjan eri vaiheissa ja lisätä erilaisia skenaarioita järjestelmän palauttamiseksi hätätilanteessa. Muistamme myös, että meillä on DevOps. Yritykset odottavat saavansa uuden tuotteen mahdollisimman nopeasti. Siksi kaikkien tarkistustemme ja komentosarjamme on oltava automatisoituja.
Tehtävä on jaettu kahteen osaan:
- kokoonpanojen laadunvalvonta testausvaiheessa (heikkolaatuisten kokoonpanojen talteenottoprosessin automatisoimiseksi);
- ohjelmistojen laadunvalvonta tuotantoympäristössä (mekanismit ongelmien automaattiseen havaitsemiseen ja mahdollisiin skenaarioihin niiden itsekorjautumiseen).
Työkalu mittareiden seurantaan ja keräämiseen
Asetettujen tavoitteiden saavuttamiseksi tarvitaan valvontajärjestelmä, joka pystyy havaitsemaan ongelmat ja siirtämään ne automaatiojärjestelmiin CI/CD-putken eri vaiheissa. On myös positiivista, jos tämä järjestelmä tarjoaa hyödyllisiä mittareita eri ryhmille: kehitys, testaus, käyttö. Ja se on aivan mahtavaa, jos se on myös bisnestä.
Mittareiden keräämiseen voidaan käyttää joukkoa erilaisia järjestelmiä (Prometheus, ELK Stack, Zabbix jne.), mutta mielestäni APM-luokan ratkaisut sopivat parhaiten näihin tehtäviin (), mikä voi yksinkertaistaa elämääsi huomattavasti.
Osana työtäni tukipalvelussa aloin tehdä vastaavaa projektia Dynatracen APM-luokan ratkaisulla. Nyt, kun työskentelen integraattorina, tunnen valvontajärjestelmämarkkinat melko hyvin. Oma subjektiivinen mielipiteeni: Dynatrace soveltuu parhaiten tällaisten ongelmien ratkaisemiseen.
Dynatrace tarjoaa vaakasuoran näkymän jokaisesta käyttäjän toiminnasta yksityiskohtaisesti koodin suoritustasoon asti. Voit seurata koko eri tietopalveluiden välistä vuorovaikutusketjua: web- ja mobiilisovellusten etutasoista, taustasovelluspalvelimista, integraatioväylästä tiettyyn tietokantapuheluun.
. Kaikkien riippuvuuksien automaattinen rakentaminen järjestelmäkomponenttien välillä
. Palvelun toimintapolun automaattinen tunnistus ja rakentaminen
Muistamme myös, että meidän on integroitava erilaisten automaatiotyökalujen kanssa. Tässä ratkaisussa on kätevä API, jonka avulla voit lähettää ja vastaanottaa erilaisia mittareita ja tapahtumia.
Seuraavaksi siirrytään yksityiskohtaisempaan tarkasteluun näiden ongelmien ratkaisemisesta Dynatrace-järjestelmän avulla.
Tehtävä 1. Kokoonpanojen laadunvalvonnan automatisointi testausvaiheessa
Ensimmäinen haaste on löytää ongelmat mahdollisimman varhaisessa vaiheessa sovelluksen toimitusprosessissa. Vain "hyvien" koodinrakennusten tulisi päästä tuotantoon. Tätä varten putkistossasi tulee testausvaiheessa olla lisänäyttöjä palvelujesi laadun tarkistamiseksi.
Katsotaanpa vaihe vaiheelta, kuinka tämä toteutetaan ja automatisoidaan:
Kuvassa on automatisoitu ohjelmiston laadun testausvaihe:
- valvontajärjestelmän käyttöönotto (agenttien asentaminen);
- tunnistaa tapahtumat ohjelmistosi laadun arvioimiseksi (mittarit ja kynnysarvot) ja siirtää ne valvontajärjestelmään;
- kuormitus- ja suorituskykytestien luominen;
- suorituskyky- ja saatavuustietojen kerääminen seurantajärjestelmään;
- ohjelmiston laadunarviointitapahtumiin perustuvien testitietojen siirto valvontajärjestelmästä CI/CD-järjestelmään. Automaattinen kokoonpanojen analysointi.
Vaihe 1. Valvontajärjestelmän käyttöönotto
Ensin sinun on asennettava agentit testiympäristöösi. Samaan aikaan Dynatrace-ratkaisussa on mukava ominaisuus - se käyttää yleisagenttia OneAgent, joka on asennettu käyttöjärjestelmän ilmentymään (Windows, Linux, AIX), tunnistaa automaattisesti palvelusi ja alkaa kerätä niistä seurantatietoja. Sinun ei tarvitse määrittää erillistä agenttia jokaiselle prosessille. Tilanne on samanlainen pilvi- ja konttialustojen osalta. Samalla voit myös automatisoida agentin asennusprosessin. Dynatrace sopii täydellisesti "infrastruktuuri koodina" -konseptiin (): Kaikille suosituille alustoille on valmiita skriptejä ja ohjeita. Upota agentti palvelusi kokoonpanoon, ja kun otat sen käyttöön, saat heti uuden palvelun jo toimivalla agentilla.
Vaihe 2: Määritä ohjelmiston laatutapahtumat
Nyt sinun on päätettävä palveluiden ja liiketoimintojen luettelosta. On tärkeää ottaa huomioon juuri ne käyttäjätoiminnot, jotka ovat palvelusi kannalta liiketoimintakriittisiä. Tässä suosittelen konsultointia yritys- ja järjestelmäanalyytikoiden kanssa.
Seuraavaksi sinun on määritettävä, mitkä tiedot haluat sisällyttää kunkin tason arvioon. Tämä voi olla esimerkiksi suoritusaika (jaettu keskiarvoon, mediaaniin, prosenttipisteisiin jne.), virheet (looginen, palvelu, infrastruktuuri jne.) ja erilaisia infrastruktuurimittareita (muistikasa, roskienkerääjä, säikeiden määrä jne.).
DevOps-tiimin automatisoimiseksi ja käytön helpottamiseksi tulee näkyviin "Monitoring as Code" -konsepti. Tarkoitan tällä sitä, että kehittäjä/testaaja voi kirjoittaa yksinkertaisen JSON-tiedoston, joka määrittää ohjelmiston laadunvarmistusmittarit.
Katsotaanpa esimerkkiä tällaisesta JSON-tiedostosta. Dynatrace API:n objekteja käytetään avain/arvo-pareina (API-kuvaus löytyy täältä ).
{
"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
}
]
}Tiedosto on joukko aikasarjamääritelmiä:
- timeseriesId – tarkistettava mittari, esimerkiksi vastausaika, virhemäärä, käytetty muisti jne.;
- aggregaatio - mittareiden yhdistämistaso, tässä tapauksessa avg, mutta voit käyttää mitä tahansa tarvitsemaasi (keskiarvo, min, maksimi, summa, määrä, prosenttipiste);
- tags – objektitunniste valvontajärjestelmässä tai voit määrittää tietyn objektin tunnisteen;
- vakava ja varoitus – nämä indikaattorit säätelevät mittareiden kynnysarvoja; jos testiarvo ylittää ankaran kynnyksen, koontiversiomme merkitään epäonnistuneeksi.
Seuraavassa kuvassa on esimerkki tällaisten kynnysarvojen käytöstä.
Vaihe 3: Latauksen luominen
Kun olemme määrittäneet palvelumme laatutasot, meidän on luotava testikuorma. Voit käyttää mitä tahansa testaustyökaluja, joista pidät, kuten Jmeter, Selenium, Neotys, Gatling jne.
Dynatracen seurantajärjestelmän avulla voit kaapata erilaisia metatietoja testeistäsi ja tunnistaa, mitkä testit kuuluvat mihin tahansa julkaisujaksoon ja mihin palveluun. On suositeltavaa lisätä ylimääräisiä otsikoita HTTP-testipyyntöihin.
Seuraavassa kuvassa on esimerkki, jossa osoitamme lisäotsikon X-Dynatrace-Test avulla, että tämä testi liittyy tuotteen ostoskoriin lisäämisen toiminnan testaamiseen.
Kun suoritat jokaisen kuormitustestin, lähetät lisätietoa asiayhteyteen liittyvistä tiedoista Dynatracelle Event API:n avulla CI/CD-palvelimelta. Tällä tavalla järjestelmä pystyy erottamaan erilaiset testit.
. Tapahtuma valvontajärjestelmässä kuormitustestauksen alkamisesta
Vaihe 4-5. Kerää suorituskykytietoja ja siirrä tiedot CI/CD-järjestelmään
Yhdessä generoidun testin kanssa seurantajärjestelmään välitetään tapahtuma tarpeesta kerätä tietoa palvelun laatuindikaattoreiden tarkistamisesta. Se määrittää myös JSON-tiedostomme, joka määrittää keskeiset mittarit.
Tapahtuma tarpeesta tarkistaa CI/CD-palvelimella luodun ohjelmiston laatu valvontajärjestelmään lähetettäväksi
Esimerkissämme laaduntarkistustapahtumaa kutsutaan perfSigDynatraceReport (Performance_Signature) - tämä on valmis integraatiota varten Jenkinsin kanssa, jonka ovat kehittäneet T-Systems Multimedia Solutionsin kaverit. Jokainen testikäynnistystapahtuma sisältää tietoja palvelusta, koontiversion numerosta ja testausajasta. Laajennus kerää suorituskykyarvot rakennusaikana, arvioi ne ja vertaa tulosta aikaisempiin koontiversioihin ja ei-toiminnallisiin vaatimuksiin.
Tapahtuma seurantajärjestelmässä rakentamisen laaduntarkistuksen alkamisesta.
Testin päätyttyä kaikki ohjelmiston laadun arvioinnin mittarit siirretään takaisin jatkuvaan integrointijärjestelmään, esimerkiksi Jenkinsiin, joka tuottaa raportin tuloksista.
CI/CD-palvelimen kokoonpanojen tilastojen tulos.
Näemme jokaisen yksittäisen koontiversion tilastot jokaiselle asettamamme mittarille koko testin ajan. Näemme myös, oliko tietyissä kynnysarvoissa (varoitus ja ankarat kynnysarvot) rikkomuksia. Koottujen mittareiden perusteella koko koontiversio on merkitty vakaaksi, epävakaaksi tai epäonnistuneeksi. Mukavuuden vuoksi voit myös lisätä raporttiin indikaattoreita, jotka vertaavat nykyistä koontiversiota edelliseen.
Tarkastele yksityiskohtaisia tilastoja kokoonpanoista CI/CD-palvelimella.
Kahden kokoonpanon yksityiskohtainen vertailu
Tarvittaessa voit siirtyä Dynatracen käyttöliittymään, jossa voit tarkastella kunkin koontiversiosi tilastoja tarkemmin ja verrata niitä keskenään.
Dynatracen koontitilastojen vertailu.
Tulokset
Tuloksena saamme "seuranta palveluna" -palvelun, joka on automatisoitu jatkuvassa integraatiossa. Kehittäjän tai testaajan tarvitsee vain määrittää JSON-tiedostossa oleva mittariluettelo, ja kaikki muu tapahtuu automaattisesti. Saamme läpinäkyvän julkaisujen laadunvalvonnan: kaikki ilmoitukset suorituskyvystä, resurssien kulutuksesta tai arkkitehtonisista regressioista.
Tehtävä 2. Ohjelmiston laadunvalvonnan automatisointi tuotantoympäristössä
Olemme siis ratkaisseet ongelman, kuinka valvontaprosessi automatisoidaan Pipelinen testausvaiheessa. Näin minimoimme tuotantoympäristöön päätyvien heikkolaatuisten kokoonpanojen osuuden.
Mutta mitä tehdä, jos huonoja ohjelmistoja myydään tai jokin vain menee rikki. Utopiaksi halusimme mekanismeja, jotka havaitsevat ongelmat automaattisesti ja, jos mahdollista, itse järjestelmän palauttavan toimivuutensa ainakin yöllä.
Tätä varten meidän on, analogisesti edellisen osion kanssa, huolehdittava automaattisista ohjelmistojen laaduntarkistuksista tuotantoympäristössä ja perustuttava skenaarioihin järjestelmän itsensä korjaamiseksi.
Automaattinen korjaus koodina
Useimmilla yrityksillä on jo kertynyt tietokanta erilaisista yleisistä ongelmista ja luettelo toimenpiteistä niiden korjaamiseksi, kuten prosessien uudelleenkäynnistäminen, resurssien puhdistaminen, versioiden peruuttaminen, virheellisten kokoonpanomuutosten palauttaminen, komponenttien määrän lisääminen tai vähentäminen klusterin, sinisen tai vihreän ääriviivan vaihtaminen jne.
Vaikka monet keskusteluryhmät, joiden kanssa puhun, ovat tunteneet nämä käyttötapaukset vuosia, harvat ovat ajatelleet tai investoineet niiden automatisointiin.
Jos ajattelet sitä, itsekorjautuvien sovellusten suorituskyvyn prosessien toteuttamisessa ei ole mitään liian monimutkaista; sinun on esitettävä järjestelmänvalvojien jo tunnetut työskenaariot koodiskriptien muodossa ("automaattinen korjaus koodina" -konsepti) , jonka kirjoitit etukäteen kustakin yksittäisestä tapauksesta. Automaattisten korjausskriptien tulee pyrkiä poistamaan ongelman perimmäinen syy. Päätät itse oikeat toimet tapaukseen reagoimiseksi.
Mikä tahansa valvontajärjestelmäsi mittari voi toimia käynnistimenä skriptin käynnistämiselle, tärkeintä on, että nämä mittarit määrittävät tarkasti, että kaikki on huonosti, koska et halua saada vääriä positiivisia tuottavassa ympäristössä.
Voit käyttää mitä tahansa järjestelmää tai järjestelmäsarjaa: Prometheus, ELK Stack, Zabbix jne. Mutta annan muutamia esimerkkejä, jotka perustuvat APM-ratkaisuun (Dynatrace on jälleen esimerkki), jotka myös helpottavat elämääsi.
Ensinnäkin kaikki liittyy suorituskykyyn sovelluksen toiminnan kannalta. Ratkaisu tarjoaa satoja eri tasoisia mittareita, joita voit käyttää laukaisimina:
- käyttäjätaso (selaimet, mobiilisovellukset, IoT-laitteet, käyttäjien käyttäytyminen, muuntaminen jne.);
- palvelun ja toiminnan taso (suorituskyky, saatavuus, virheet jne.);
- sovellusinfrastruktuurin taso (isäntäkäyttöjärjestelmän mittarit, JMX, MQ, verkkopalvelin jne.);
- alustatasolla (virtualisointi, pilvi, kontti jne.).
Tasojen valvonta Dynatracessa.
Toiseksi, kuten sanoin aiemmin, Dynatracella on avoin API, mikä tekee siitä erittäin helpon integroinnin useisiin kolmannen osapuolen järjestelmiin. Esimerkiksi ilmoituksen lähettäminen automaatiojärjestelmään, kun ohjausparametrit ylittyvät.
Alla on esimerkki vuorovaikutuksesta Ansiblen kanssa.
Alla annan muutaman esimerkin siitä, millaista automaatiota voidaan tehdä. Tämä on vain osa tapauksista; vain mielikuvituksesi ja valvontatyökalujesi ominaisuudet voivat rajoittaa niiden luetteloa ympäristössäsi.
1. Huono käyttöönotto – version palautus
Vaikka testaammekin kaiken erittäin hyvin testiympäristössä, on silti mahdollisuus, että uusi julkaisu voi tappaa sovelluksesi tuotantoympäristössä. Samaa inhimillistä tekijää ei ole kumottu.
Seuraavasta kuvasta nähdään, että palvelun toimintojen suoritusajassa on jyrkkä hyppy. Tämän hypyn alku on sama kuin sovelluksen käyttöönottoajankohta. Välitämme kaiken tämän tiedon tapahtumina automaatiojärjestelmään. Jos palvelun suorituskyky ei palaa normaaliksi asettamamme ajan jälkeen, kutsutaan automaattisesti komentosarja, joka palauttaa version vanhaan.
Toiminnan suorituskyvyn heikkeneminen käyttöönoton jälkeen.
2. Resurssien lataus 100 % - lisää solmu reititykseen
Seuraavassa esimerkissä valvontajärjestelmä määrittää, että yksi komponenteista on 100 % CPU-kuormituksessa.
CPU kuormitus 100 %
Tälle tapahtumalle on olemassa useita erilaisia skenaarioita. Valvontajärjestelmä esimerkiksi tarkistaa lisäksi, liittyykö resurssien puute palvelun kuormituksen kasvuun. Jos näin on, suoritetaan komentosarja, joka lisää automaattisesti solmun reititykseen, mikä palauttaa järjestelmän toimivuuden kokonaisuudessaan.
Skaalaus tapahtuman jälkeen
3. Kiintolevyn tilan puute - levyn puhdistus
Uskon, että monet ihmiset ovat jo automatisoineet nämä prosessit. APM:n avulla voit myös valvoa levyalijärjestelmän vapaata tilaa. Jos levytilaa ei ole tai levy toimii hitaasti, kutsumme komentosarjan sen puhdistamiseksi tai lisäämiseksi.
Levyn lataus 100 %
4. Alhainen käyttäjäaktiivisuus tai alhainen konversio - vaihtaminen sinisten ja vihreiden oksien välillä
Näen usein asiakkaiden käyttävän kahta silmukkaa (sini-vihreä käyttöönotto) sovelluksiin tuotantoympäristössä. Näin voit vaihtaa nopeasti toimipisteiden välillä, kun toimitat uusia julkaisuja. Usein käyttöönoton jälkeen voi tapahtua dramaattisia muutoksia, jotka eivät ole heti havaittavissa. Tässä tapauksessa suorituskyvyn ja saatavuuden heikkenemistä ei ehkä havaita. Jotta tällaisiin muutoksiin reagoidaan nopeasti, on parempi käyttää erilaisia mittareita, jotka kuvastavat käyttäjän käyttäytymistä (istuntojen ja käyttäjien toimien määrä, tulos, poistumisprosentti). Seuraavassa kuvassa on esimerkki, jossa konversioprosentin laskiessa tapahtuu ohjelmistohaarojen välistä vaihtoa.
Konversioprosentti laskee ohjelmistohaarojen välillä vaihtamisen jälkeen.
Mekanismit automaattiseen ongelmien havaitsemiseen
Lopuksi annan sinulle vielä yhden esimerkin siitä, miksi pidän Dynatracesta eniten.
Tarinani osassa, joka koskee kokoonpanojen laaduntarkistusten automatisointia testiympäristössä, määritimme kaikki kynnysarvot manuaalisesti. Tämä on normaalia testiympäristössä, testaaja itse määrittää indikaattorit ennen jokaista testiä kuormituksesta riippuen. Tuotantoympäristössä on toivottavaa, että ongelmat havaitaan automaattisesti ottaen huomioon erilaiset perusmekanismit.
Dynatracessa on mielenkiintoisia sisäänrakennettuja tekoälytyökaluja, jotka perustuvat mekanismeihin, joilla määritetään poikkeavia mittareita (perustaja) ja rakennetaan kaikkien komponenttien välinen vuorovaikutuskartta, vertailevat ja korreloivat tapahtumia keskenään, määrittävät poikkeamat palvelusi toiminnassa ja tarjoavat yksityiskohtaisia tietoja. tiedot jokaisesta ongelmasta ja perimmäisestä syystä.
Analysoimalla automaattisesti komponenttien välisiä riippuvuuksia Dynatrace määrittää paitsi onko ongelmallinen palvelu perimmäinen syy, myös sen riippuvuuden muista palveluista. Alla olevassa esimerkissä Dynatrace tarkkailee ja arvioi automaattisesti jokaisen palvelun kunnon tapahtuman suorittamisen aikana ja tunnistaa Golang-palvelun perimmäiseksi syyksi.
Esimerkki vian perimmäisen syyn määrittämisestä.
Seuraava kuva näyttää prosessin, jolla sovelluksesi ongelmia seurataan tapahtuman alusta alkaen.
Nousevan ongelman visualisointi kaikkien komponenttien ja niissä olevien tapahtumien näyttämisellä
Valvontajärjestelmä keräsi täydellisen kronologian syntyneeseen ongelmaan liittyvistä tapahtumista. Aikajanan alla olevassa ikkunassa näemme kaikki tärkeimmät tapahtumat jokaisessa komponentissa. Näiden tapahtumien perusteella voit määrittää menettelyt automaattiselle korjaukselle koodiskriptien muodossa.
Lisäksi suosittelen integroimaan valvontajärjestelmän Service Deskiin tai bug trackeriin. Ongelman ilmetessä kehittäjät saavat nopeasti täydelliset tiedot analysoidakseen niitä kooditasolla tuotantoympäristössä.
Johtopäätös
Tuloksena päädyimme CI/CD-putkilinjaan, jossa on sisäänrakennettu automaattinen ohjelmiston laaduntarkistus Pipelinessa. Minimoimme huonolaatuisten kokoonpanojen määrän, lisäämme järjestelmän luotettavuutta kokonaisuutena ja jos järjestelmämme edelleen epäonnistuu, käynnistämme mekanismeja sen palauttamiseksi.
Ohjelmiston laadunvalvonnan automatisointiin kannattaa ehdottomasti panostaa; se ei aina ole nopea prosessi, mutta ajan myötä se kantaa hedelmää. Suosittelen, että kun olet ratkaissut uuden tapauksen tuotantoympäristössä, mietit heti, mitkä monitorit testausympäristöön kannattaa lisätä, jotta huonon koontiversion ei pääse tuotantoon, ja luot myös komentosarjan, joka korjaa nämä ongelmat automaattisesti.
Toivon, että esimerkkini auttavat sinua pyrkimyksissäsi. Olen myös kiinnostunut näkemään esimerkkejäsi mittareista, joita käytetään itseparannusjärjestelmien toteuttamiseen.
Lähde: will.com