Jos yrityksesi on juuri esittelemässä DevOps- tai CI/CD-työkaluja, voi olla hyödyllistä tutustua yleisimpiin virheisiin, jotta et toista niitä ja et astu jonkun toisen haravalle.
Joukkue kääntänyt artikkelin .
Valmistautumattomuus muuttamaan kulttuuria ja prosesseja
Jos katsot syklistä kaaviota , on selvää, että DevOps-käytännöissä testaus on jatkuvaa toimintaa, joka on olennainen osa jokaista käyttöönottoa.
DevOps Infinite Cycle Chart
Testaus ja laadunvarmistus kehityksen ja toimituksen aikana ovat olennainen osa kaikkea kehittäjien tekemistä. Tämä vaatii ajattelutavan muutosta, jotta testaus voidaan sisällyttää jokaiseen tehtävään.
Testauksesta tulee osa jokaisen tiimin jäsenen päivittäistä työtä. Jatkuvaan testaukseen siirtyminen ei ole helppoa, sinun on valmistauduttava siihen.
Palautteen puute
DevOpsin tehokkuus riippuu jatkuvasta palautteesta. Jatkuva parantaminen on mahdotonta, ellei yhteistyölle ja kommunikaatiolle ole tilaa.
Yritysten, jotka eivät järjestä retrospektiivisiä kokouksia, on vaikea toteuttaa jatkuvan palautteen kulttuuria CI/CD:ssä. Jokaisen iteraation lopussa pidetään retrospektiiviset tapaamiset, joiden aikana tiimin jäsenet keskustelevat, mikä meni hyvin ja mikä huonosti. Retrospektiiviset kokoukset ovat Scrum/Agilen perusta, mutta ne ovat myös välttämättömiä DevOpsille.
Tämä johtuu siitä, että takautuvat tapaamiset juurruttavat tapana vaihtaa palautetta ja mielipiteitä. Yksi tärkeimmistä asioista aloituksessa on toistuvien retrotapaamisten järjestäminen niin, että niistä tulee ymmärrettäviä ja tuttuja koko tiimille.
Mitä tulee ohjelmiston laatuun, kaikki tiimin jäsenet ovat vastuussa sen ylläpitämisestä. Kehittäjät voivat esimerkiksi kirjoittaa yksikkötestejä ja myös koodia testattavuutta ajatellen, mikä auttaa vähentämään riskejä alusta alkaen.
Yksi yksinkertainen tapa heijastaa testausajattelun muutosta on kutsua testaajia QA:n sijaan ohjelmistotestaajaksi tai laatuinsinööriksi. Tämä muutos saattaa tuntua liian yksinkertaiselta tai jopa typerältä. Mutta jonkun kutsuminen "ohjelmiston laadunvarmistushenkilöksi" antaa väärän käsityksen siitä, kuka on vastuussa tuotteen laadusta. Agile-, CI/CD- ja DevOps-käytännöissä jokainen on vastuussa ohjelmiston laadusta.
Toinen tärkeä asia on ymmärtää, mitä laatu tarkoittaa koko tiimille ja jokaiselle sen jäsenelle, organisaatiolle ja sidosryhmille.
Väärinkäsitys vaiheen valmistumisesta
Jos laatu on jatkuva ja yleinen prosessi, tarvitaan yhteinen käsitys vaiheen valmistumisesta. Mistä tietää, kun vaihe on ohi? Mitä tapahtuu, kun vaihe merkitään suoritetuksi Trellolle tai muulle Kanban-taululle?
Definition of Done (DoD) on tehokas työkalu CD DevOps/CI:n yhteydessä. Se auttaa ymmärtämään paremmin laatustandardeja sille, mitä ja miten tiimi rakentaa.
Kehitystiimin on päätettävä, mitä "Valmis" tarkoittaa. Heidän on istuttava alas ja tehtävä luettelo ominaisuuksista, jotka on täytettävä kussakin vaiheessa, jotta se katsottaisiin täydelliseksi.
DoD tekee prosessista läpinäkyvämmän ja helpottaa CI/CD:n käyttöönottoa, jos kaikki tiimin jäsenet ymmärtävät sen ja siitä sovitaan yhdessä.
Realististen, selkeästi määriteltyjen tavoitteiden puute
Tämä on yksi useimmin lainatuista neuvoista, mutta se kannattaa toistaa. Menestyäksesi missä tahansa suuressa hankkeessa, mukaan lukien CI/CD tai DevOps, sinun on asetettava realistiset tavoitteet ja mitattava suorituskykyä niihin nähden. Mitä yrität saavuttaa CI/CD:llä? Mahdollistaako tämä nopeammat julkaisut paremmalla laadulla?
Kaikkien asetettujen tavoitteiden tulee olla läpinäkyviä ja realistisia, vaan niiden tulee myös olla johdonmukaisia yrityksen nykyisen toiminnan kanssa. Kuinka usein asiakkaasi esimerkiksi tarvitsevat uusia korjaustiedostoja tai versioita? Ei ole tarvetta ylikuormittaa prosesseja ja vapauttaa nopeammin, jos siitä ei ole lisähyötyä käyttäjille.
Lisäksi sinun ei aina tarvitse toteuttaa sekä CD:tä että CI:tä. Esimerkiksi tiukasti säännellyt yritykset, kuten pankit ja lääkäriasemat, voivat työskennellä vain CI:n kanssa.
CI toimii hyvänä lähtökohtana kaikille DevOpsia toteuttaville yrityksille. Kun se otetaan käyttöön, yritysten lähestymistapa ohjelmistotoimitukseen muuttuu merkittävästi. Kun CI on hallittu, voit ajatella koko prosessin parantamista, käyttöönottonopeuden lisäämistä ja muita muutoksia.
Monille organisaatioille CI yksin riittää, ja CD tulisi ottaa käyttöön vain, jos se tuo lisäarvoa.
Asianmukaisten kojetaulujen ja mittareiden puute
Kun olet asettanut tavoitteesi, kehitystiimi voi luoda koontinäytön KPI-arvojen mittaamiseksi. Ennen sen kehittämistä kannattaa arvioida, mitä parametreja seurataan.
Erilaiset raportit ja sovellukset ovat hyödyllisiä eri tiimin jäsenille. Scrum Master on enemmän kiinnostunut asemasta ja ulottuvuudesta. Ylin johto saattaa olla kiinnostunut asiantuntijoiden työuupumusasteesta.
Jotkut tiimit käyttävät myös kojelautaa punaisilla, keltaisilla ja vihreillä indikaattoreilla arvioidakseen CI/CD:n tilaa ymmärtääkseen, tekevätkö he kaiken oikein vai onko kyseessä virhe. Punainen tarkoittaa, että sinun on kiinnitettävä huomiota siihen, mitä tapahtuu.
Kuitenkin, jos kojelaudat eivät ole standardoituja, ne voivat olla harhaanjohtavia. Analysoi, mitä tietoja jokainen tarvitsee, ja luo sitten standardoitu kuvaus siitä, mitä se tarkoittaa. Ota selvää, mikä on järkevämpää sidosryhmille: grafiikka, teksti vai numerot.
Ei manuaalisia testejä
Testausautomaatio luo perustan hyvälle CI/CD-putkilinjalle. Mutta automaattinen testaus kaikissa vaiheissa ei tarkoita, että sinun ei pitäisi suorittaa manuaalista testausta.
Tehokkaan CI/CD-putkilinjan rakentamiseksi tarvitset myös manuaalisia testejä. Testauksessa on aina joitain näkökohtia, jotka vaativat ihmisen analysointia.
On syytä harkita manuaalisen testauksen integrointia prosessiisi. Kun joidenkin testitapausten manuaalinen testaus on valmis, voit siirtyä käyttöönottovaiheeseen.
Älä yritä parantaa testejä
Tehokas CI/CD-putki vaatii pääsyn oikeisiin työkaluihin, olipa kyseessä sitten testien hallinta tai integrointi ja jatkuva seuranta.
Vahvan, laatusuuntautuneen kulttuurin luominen tähtää , seurata asiakkaiden vuorovaikutusta käyttöönoton jälkeen ja seurata parannuksia.
Tässä muutamia käytännön vinkkejä, jotka voit helposti toteuttaa:
- Varmista, että testit ovat helppoja kirjoittaa ja riittävän joustavia, jotta ne eivät katkea, kun muokkaat koodia uudelleen.
- Kehitystiimit tulisi ottaa mukaan testausprosessiin – katso luettelo käyttäjäongelmista ja pyynnöistä, jotka ovat tärkeitä testattavana CI-putkien aikana.
- Sinulla ei välttämättä ole täyttä testikattavuutta, mutta varmista aina, että UX:n ja asiakaskokemuksen kannalta tärkeät virrat testataan.
Viimeisenä mutta ei vähäisimpänä tärkeä kohta
Siirtyminen CI/CD:hen ohjataan yleensä alhaalta ylöspäin, mutta viime kädessä se on muutos, joka vaatii yritykseltä johtajuutta, aikaa ja resursseja. CI/CD on loppujen lopuksi joukko taitoja, prosesseja, työkaluja ja kulttuurisia uudelleenjärjestelyjä, ja tällaisia muutoksia voidaan toteuttaa vain systemaattisesti.
Mitä muuta luettavaa aiheesta:
- .
- .
- .
Lähde: will.com