Devops voi olla yksi huonoimmista termeistä ohjelmistokehityksessä, mutta useimmat meistä ovat yhtä mieltä siitä, että viisi toimintaa tekee devopsista sen mitä se on: jatkuva integrointi, jatkuva toimitus, pilvi-infrastruktuuri, testausautomaatio ja kokoonpanon hallinta. Jos teet nämä viisi asiaa, teet devopsia. On selvää, että kaikki viisi ovat tärkeitä oikeaksi pääsemiseksi, mutta aivan liian helposti väärin. Erityisesti jatkuva integrointi ja jatkuva jakelu (CI / CD) voivat olla vaikeimpia devops-siirtoja hallita.
Jatkuva integraatio (CI) on prosessi, jossa kehittäjät ja testaajat validoivat uuden koodin yhteistyössä. Perinteisesti kehittäjät kirjoittivat koodin ja integroivat sen kerran kuukaudessa testausta varten. Se oli tehotonta - virhe neljän viikon takaisessa koodissa saattoi pakottaa kehittäjät tarkistamaan viikko sitten kirjoitetun koodin. Tämän ongelman voittamiseksi CI riippuu automaatiosta integroimaan ja testaamaan koodia jatkuvasti. CI-joukkueet, jotka käyttävät CI: tä, sitoutuvat koodiin vähintään päivittäin, kun taas suurin osa heistä antaa koodin jokaiselle muutokselle.
Jatkuva toimitus (CD) on prosessi, jossa jatkuvasti irrotettavia esineitä luodaan. Jotkut yritykset julkaisevat käyttäjille kerran tai jopa useita kertoja päivässä, kun taas toiset julkaisevat ohjelmiston hitaammin markkinoiden syistä. Kummassakin tapauksessa vapautuskykyä testataan jatkuvasti. Jatkuva käyttöönotto on mahdollista pilviympäristöjen ansiosta. Palvelimet on määritetty siten, että voit ottaa ne käyttöön tuotantoon sammuttamatta palvelimia manuaalisesti.
CI / CD on siis prosessi uuden koodin jatkuvaan kehittämiseen, testaamiseen ja toimittamiseen. Jotkut yritykset, kuten Facebook ja Netflix, käyttävät CI / CD-levyä viimeistään 10 tai enemmän julkaisuja viikossa. Muut yritykset kamppailevat saavuttaakseen kyseisen tahdin, koska he antautuvat yhdelle tai useammalle viidestä sudenkuopasta, joista keskustelen seuraavaksi.
CI / CD-pudotus # 1: Väärien prosessien automatisointi ensin
Tämä ansa on taipuvainen iskemään organisaatioita, jotka siirtyvät vesiputousten kehityksestä devopsiin. Uusilla organisaatioilla on etu toteuttaa CI / CD tyhjästä. Nykyisten yritysten on siirryttävä asteittain manuaalisesta kehitykseen automatisoituun kehitykseen. Täysi siirtyminen voi kestää useita kuukausia, mikä tarkoittaa, että sinun on oltava iteratiivinen CI / CD: n käyttöönotossa.
Kun kysyt: "Onko tämä nyt automatisoitava?" Suorita seuraava tarkistuslista:
- Kuinka usein prosessi tai skenaario toistetaan?
- Kuinka kauan prosessi on?
- Mitkä ihmiset ja resurssiriippuvuudet ovat mukana prosessissa? Aiheuttavatko ne viivästyksiä CI / CD: ssä?
- Onko prosessivirhe altis, jos sitä ei ole automatisoitu?
- Mikä on prosessin automatisoinnin kiireellisyys?
Tämän tarkistuslistan avulla voit priorisoida CI / CD-toteutuksen vaiheet. Ensinnäkin automatisoi koodin kokoamisprosessi. Ihannetapauksessa integroit koodin useita kertoja päivässä (1). Manuaalisesti prosessi kestää muutamasta minuutista pariin tuntiin (2). Se pysäyttää lähdön, kunnes kääntäjä viimeistelee tehtävän (3). Se on myös altis inhimillisille erehdyksille (4), ja koska CI / CD on unelma ilman automaattista integraatiota, tämä on kiireellistä (5).
Voimme suorittaa saman tarkistuslistan testauksessa. Kun siirryt CI / CD-levylle, saatat miettiä: Pitäisikö meidän ensin automatisoida toiminnallinen testaus vai käyttöliittymän testaus? Molemmat toistetaan vähintään kerran päivässä (1). Molemmat voivat kestää kaksi tai kolme tuntia keskikokoisessa sovelluksessa (2). Mutta niihin liittyy useita riippuvuuksia (3). Jos automatisoit toiminnallisen testauksen, sinun ei tarvitse päivittää automaatiokomentosarjaa niin usein. Toisaalta käyttöliittymä muuttuu usein ja vaatii siten usein komentosarjojen muutoksia. Vaikka molemmat ovat virheiden alaisia (4), sinun tulisi priorisoida toiminnallinen testaus ennen käyttöliittymän testausta resurssien parhaan hyödyntämiseksi (5).
Tehdään tämä vielä kerran ympäristöjen asettamisprosessilla. Tätä skenaariota toistetaan usein vain, jos olet töissä tai sinulla on voimakas vaihtelu (1). Se on melko aikaa vievä prosessi, joka voi kestää useita tunteja, ellei päiviä (2). Uudet tiimin jäsenet eivät voi tehdä mitään hyödyllistä ilman ympäristöjä, joten riippuvuus ja viive ovat selvästi olemassa (3). En sanoisi, että prosessi on altis virheille (4), joten onko se edelleen kiireellistä (5)? Kallistun kyllä, mutta priorisoin silti ensin integraation ja toiminnalliset testaukset.
Ei ole olemassa yliannostelua. Jos sinulla olisi rajattomat resurssit, automatisoit kaiken mahdollisen. Se sanoi, sinä ei voi saavuttaa täydellinen testausautomaatio. Joskus voit jakaa tehtävät pienempiin segmentteihin ja automatisoida korjaustiedostoina. Joskus sinun pitäisi yksinkertaisesti dokumentoida prosessi yksityiskohtaisesti ja suorittaa se manuaalisesti.
CI / CD-pudotus # 2: Jatkuva jatkuva käyttöönotto jatkuvaa toimitusta varten
Jatkuva käyttöönotto on käsite, että jokainen koodipohjaan tehty muutos otetaan käyttöön melkein välittömästi tuotantoon, jos putkilinjan tulokset onnistuvat. Tämä on kauhistuttavaa useimmille organisaatioille, koska nopeat tuotemuutokset voivat pelotella käyttäjiä.
Yritykset uskovat, että jos he eivät harjoittele jatkuvaa käyttöönottoa, he eivät tee CD-levyjä. He eivät erota jatkuvaa käyttöönottoa ja jatkuvaa toimitusta.
Jatkuva toimitus on käsite, että jokainen muutos koodikantaan kulkee putkilinjan läpi siihen pisteeseen asti, jossa se otetaan käyttöön tuotantoympäristöihin. Tiimi löytää ja käsittelee ongelmat välittömästi, ei myöhemmin, kun he aikovat vapauttaa koodipohjan.
Koodipohja on aina turvallisella julkaisutasolla. Kun Koodipohjan vapauttaminen tuotantoon on liiketoiminnan päätös.
Vaikka jatkuva käyttöönotto hämmentää useimpia organisaatioita, jatkuva toimitus resonoi heidän kanssaan. Jatkuva toimitus antaa heille mahdollisuuden hallita tuotteen käyttöönottoa, toimivuutta ja riskitekijöitä. On aikaa alfa-testaukseen, beeta-asiakkaille, varhaisille käyttöönottajille ja niin edelleen.
CI / CD-pudotus # 3: Merkityksellisten mittaristojen ja mittareiden puute
CI / CD-toteutuksissa scrum-tiimi voi luoda hallintapaneelin, ennen kuin jäsenet tietävät, mitä heidän on seurattava. Tämän seurauksena joukkue joutuu loogisen harhaan saaliiksi: "Nämä ovat mittareita, joten niiden on oltava tärkeitä." Suorita sen sijaan asteittainen arviointi ennen kojelaudan suunnittelu.
Eri IT-organisaation jäsenillä ja jopa useilla tutkintaryhmän jäsenillä on erilaiset prioriteetit. Esimerkiksi verkon operointikeskuksen (NOC) ihmiset rakastavat punaisia, keltaisia ja vihreitä osoittimia. Tällaiset liikennevalojen kojelaudat antavat NOC-henkilöstölle mahdollisuuden erottaa ongelmat lukematta tiheää tekstiä tai verottamatta heidän analyyttisiä kykyjään. Liikennevalot auttavat satoja palvelimia hallittaviksi.
Saatat olla houkutus käyttää liikennevalojen kojelautaa myös CI / CD-levyihin. Vihreä, olemme tiellä. Keltainen, olemme raiteilta, mutta meillä on suunnitelma puuttua siihen. Punainen, olemme raiteilta ja meidän on todennäköisesti muutettava tavoitteitamme.
Kojelauta on todennäköisesti hyödyllinen scrum masterille, mutta entä kehityksen varapääjohtaja tai CTO? Jos tutkintaryhmällä on 350 tuntia työtä kahden viikon sprintissä ja sen 10 jäsentä on vastuussa 35 tunnista, he saavat vastaavan määrän tarinapisteitä. Ylin johto saattaa olla vähemmän kiinnostunut tarinapisteiden tilasta ja utelias "palamisen" nopeudesta: tehtävän suorittamisen nopeudesta. Kuljettavatko tiimin jäsenet kuormansa? Kuinka nopeasti? Parantuvatko ne ajan myötä?
Valitettavasti palamisprosentit saattavat olla harhaanjohtavia, jos eri sidosryhmät eivät ymmärrä rummutiimin sovittuja tapoja. Jotkut joukkueet polttavat pisteitä varhaisessa vaiheessa. Toiset odottavat sprintin loppupuolella, jotta palavat avoimet kohdat. Kojelaudan tulisi ottaa tämä huomioon.
Jos pystyt arvioimaan, mitä tietoja kaikki haluavat, ja luomaan tavallisen kertomuksen tietojen merkityksestä, voit suunnitella hyödyllisen hallintapaneelin. Mutta älä pakota sisältöä ulkonäön kustannuksella. Kysy miltä sidosryhmät haluavat sen näyttävän. Ovatko kaaviot, teksti tai numerot parhaita?
Nämä ovat näkökohtia, joita on tutkittava asteittaisessa arvioinnissa. Ne kuvaavat kuinka hankalaa on tehdä hyödyllinen CI / CD-kojelauta - ja tehdä kaikki onnelliseksi. Liian usein äänekkäämpi tiimin jäsen kaapaa prosessin, ja toiset tuntevat turhautumista siitä, että kojelauta täyttää vain yhden henkilön mieltymykset. Kuuntele kaikkia.
CI / CD-pudotus # 4: Jatkuvan integraation ja jatkuvan toimituksen välinen koordinoinnin puute
Tämä kuoppa vie meidät takaisin yksimieliseen määritelmään devops, jonka mukaan jatkuva integrointi ja jatkuva toimitus ovat kaksi erilaista asiaa. CI syötteet CD. Kunnollisen jatkuvan integrointiputken ja täydellisen jatkuvan jakelujärjestelmän toteuttaminen vie kuukausia ja vaatii yhteistyötä. Laadunvarmistuksen, devops-tiimin, op-insinöörien, scrum-mestareiden - kaikkien on osallistuttava. Ehkä vaikein osa CI / CD: tä on tämä inhimillinen tekijä eikä mikään tekninen haaste, josta olemme keskustelleet. Aivan kuten et voi ohjelmoida terveellistä suhdetta kahden ihmisen välille, et voi automatisoida yhteistyötä ja viestintää.
Tämän koordinaation tason arvioimiseksi vertaile CI / CD-prosessiasi liiketoiminnan parhaisiin. Netflixin kaltaiset yritykset voivat suorittaa integroinnin, testauksen ja toimituksen kahdessa tai kolmessa tunnissa. He perustivat järjestelmän, joka välittää koodin kädestä käteen ilman päättämättömyyttä ja keskustelua. Ei, se ei ole täysin automatisoitu, koska se on mahdotonta nykyisellä tekniikalla.
CI / CD-pudotus # 5: Jatkuvien integraatiotöiden ja resurssien käytön tasapainottaminen
Jatkuvien integraatiotöiden odotetaan käynnistyvän jokaisessa koodissa esitetyssä muutoksessa. Menestyneet työt antavat muutosten käydä läpi, kun epäonnistumiset hylkäävät muutokset. Tämä kannustaa kehittäjiä tarkistamaan pienempiä koodinpaloja, mikä lisää päivityksiä päivässä. Tarpeettomat jatkuvan integraation työpaikat kuluttavat kuitenkin resursseja, mikä tuhlaa aikaa ja rahaa.
Koska tähän prosessiin liittyy paljon resurssien käyttöä (prosessori, teho, aika), ohjelmisto on jaettava pienempiin komponentteihin, jotta voidaan luoda nopeammin kulkevat putkilinjat. Tai jatkuvan integroinnin työt tulisi suunnitella eräkirjautumisille, jotka testataan ensin paikallisesti. Tavoitteena on löytää tasapaino jatkuvien integraatiotöiden suorittamisen ja resurssien käytön välillä.
Pidä tavoite näkyvissä
Kun kaivamme CI / CD: n sudenkuoppia - täydellisenä esoteerisella terminologialla - on helppo unohtaa miksi tällä on merkitystä. Viime kädessä CI / CD on välttämätön, koska se täyttää liiketoiminnan tavoitteet.
Teknologiajohtajat tietävät, että jatkuva kehitys, pikakorjaukset ja laadukkaat tulokset luovat ja pitävät asiakkaita. He tietävät, että epäonnistunut julkaisu kutsuu bludgen App Storen arvosteluihin, ja korkeiden arvostelujen palauttaminen on vaikeampi kuin niiden pitäminen. Devops saattaa luoda paremman työkokemuksen tiimillesi, mutta siksi yritykset eivät toteuta devopsia.
Yksinkertaisesti sanottuna CI / CD: n sudenkuopat on syytä tarkistaa, koska vaakalaudalla on miljardeja dollareita. Vaikka en suosittele, että lisäät osakekurssin tai App Storen tarkistusseurannan CI / CD-kojelautaan, kehotan teitä pysymään tietoisena tästä. Paljon riippuu CI / CD: n yksityiskohdista.
Zubin Irani on perustaja ja toimitusjohtaja cPrimelle, joka on täyden palvelun konsulttiyritys, joka toteuttaa ketterät muutokset ja toimittaa ketterät ratkaisut yli 50 Fortune 100 -yritykselle ja monille Piilaakson suurimmille työnantajille.
New Tech Forum tarjoaa mahdollisuuden tutkia ja keskustella kehittyvistä yritysteknologioista ennennäkemättömällä syvyydellä ja laajuudella. Valinta on subjektiivinen, perustuu valitsemiemme tekniikoihin, joiden uskomme olevan tärkeitä ja kiinnostavia lukijoille. ei hyväksy markkinointivakuuksia julkaisua varten ja pidättää oikeuden muokata kaikkea lähetettyä sisältöä. Lähetä kaikki tiedustelut osoitteeseen [email protected].
