Continuous Integration, Delivery ja Deployment: Mitä eroa niillä on?

Tällä kertaa CI/CD eli Continuous Integration ja Continuous Delivery/Continuous Deployment rakentuvat luontevasti toistensa päälle. Kaikki kolme ovat DevOpsin tavoitteiden ytimessä. On siis aika selvittää, mitä lyhenteet tarkoittavat.

Mitä Continuous Integration tarkoittaa?

Ensimmäinen vaihe on CI eli Continuous Integration.

Continuous Integrationissa kehittäjän tekemä ja valmiiksi ilmoittama koodimuutos commitoidaan etärepositorioon. Tämän jälkeen uusi, muuttunut koodi kokonaisuudessaan käy palvelimella läpi joukon automatisoituja testejä. Testit, joihin kuuluvat muun muassa regressiotestit, varmistavat, ettei uusia ominaisuuksia lisättäessä tai nykyisiä parannettaessa menetetä olemassa olevia toiminnallisuuksia.

Paras käytäntö on kuitenkin käyttää hyväksyntään perustuvia committeja. Tämä tarkoittaa, että yksittäisen henkilön juuri commitoima koodi testataan ennen kuin se jaetaan muille kehittäjille tai testaajille. Tämä kannustaa tekemään pieniä muutoksia, jotka yhdistetään usein. Muutokset ovat näin selkeitä, ja ohjelmiston tila paranee jatkuvasti, koska uusi koodi testataan.

Eficodelaisen opinnäytetyötä lainaten: ”Continuous Integration kehitettiin ratkaisemaan \[a\] peräkkäisen ohjelmistokehitysmallin ongelmia. Kun vaatimus-, analyysi-, suunnittelu- ja toteutusvaiheet oli saatu päätökseen, ohjelmistoprojektin integrointivaiheessa kohdattiin usein merkittäviä ongelmia.” (sivu 11)

Yhteenvetona Continuous Integration tarkoittaa uuden koodin lisäämistä usein, ja nykyään se käynnistää useimmissa tapauksissa automatisoidut testit. Useimpien mukaan se on CD:n eli Continuous Deliveryn edellytys.

CI sijoittuu siis prosessissa ennen Continuous Deliverya ja Continuous Deploymentia, joihin siirrymme seuraavaksi.

Mitä eroa on Continuous Deliverylla ja Continuous Deploymentilla?

CD voi tarkoittaa Continuous Deploymentia tai Continuous Deliverya. Näiden kahden DevOps-lähestymistavan välillä on vain yksi pieni ero, joka löytyy viimeisestä vaiheesta.

Deployment määritellään yleensä sovelluksen viemiseksi tiettyyn ympäristöön. Tavallisesti kyseessä on käyttäjien käyttämä tuotantoympäristö.

Jos sovellus toimii verkkosivustolla tai sitä hallinnoi keskitetty IT-osasto, käyttäjillä ei ole muuta vaihtoehtoa kuin käyttää sitä. Deployment voi silti sisältää ominaisuuksia, joista käyttäjät eivät tiedä (niin sanottu ”dark launch”) ja joita testataan tulevaa julkaisua varten. Kuten sana itsessään kertoo, julkaisusta tiedotetaan julkisesti. Ladattavan ohjelmiston kohdalla käyttäjä voi myös enemmän tai vähemmän itse päättää, kokeileeko hän sitä.

Continuous Deliveryssa sovellus viedään hyväksyntätestien kautta eristettyyn (testi)ympäristöön vaiheeseen, jossa käyttöönotto tuotantoon on vain napin painalluksen päässä. Yleensä napin painaminen edellyttää johdon strategista päätöstä.

Tai kuten Eficoden Severi Haverila totesi opinnäytetyössään: ”...Continuous Deliveryn keskeinen periaate on pitää ohjelmisto jatkuvasti käyttöönotettavassa tilassa.” (sivu 11)

Continuous Deployment (eli automatisoitu deployment) on automaattinen prosessi aina loppukäyttäjille asti. Molempien CD-mallien tekninen toteutus on siksi käytännössä sama: koko deployment-prosessin automatisointi sekä viimeisen vaiheen pitäminen manuaalisesti hallittavana, jos tavoitteena on Continuous Delivery.

Keskustelu jatkuu!

Kuten kaikista määritelmistä – myös DevOpsin määritelmästä – käydään keskustelua siitä, mikä määritelmä on lopullinen.

Johtavat työkalutoimittajat, kuten Atlassian ja Puppet, vaikuttavat päätyneen CI/CD:stä jokseenkin samanlaiseen käsitykseen kuin tässä tekstissä aiemmin esitetty.

On ehkä vielä liian aikaista sanoa, voidaanko sitä pitää vakiintuneena määritelmänä. Kuten kaikki muutkin laajasti käytetyt termit, sekin on aina määriteltävä asianmukaisesti kulloisenkin käyttötapauksen yhteydessä.

Samaan aikaan tulevaisuuden opiskelijoiden on opittava myös vasta muotoutuvia lyhenteitä. Koko toimiala vaikuttaa kuitenkin olevan yhtä mieltä siitä, että CI/CD tai yleisemmin automaatio tuo kehittäjät ja ylläpidon lähemmäs toisiaan.

Sen pitäisi lopulta auttaa kehitettyä ohjelmistoa tuottamaan arvoa nopeammin.