CI/CD-putken yleiskatsaus: miksi sinun pitäisi tietää siitä

Jatkuva integraatio ja jatkuva toimitus (CI/CD) ovat gravitaatiokenttiä, joiden ympärillä moderni DevOps-työnkulku kiertää. Organisaatioiden, jotka haluavat tuottaa kustannustehokasta ja suhteellisen virheetöntä koodia nopeasti, on omaksuttava CI/CD-putket ohjelmistojen toimitusjärjestelmänsä elintärkeäksi arkkitehtuuriksi.

Ennen kuin jatkuvan integraation ja jatkuvan toimituksen putket yleistyivät, koodimuutokset vietiin tuotantojärjestelmiin manuaalisesti tilapäisten työnkulkujen kautta, usein ilman standardoitua testausta. Onneksi olen selvinnyt kertomaan hyytävistä kokemuksistani ohjelmistojen testausympäristöissä, joista nämä elintärkeät prosessit puuttuivat.

Toisaalta olen nähnyt omakohtaisesti, kuinka CI/CD-työkalut ja -prosessit tarjoavat tehokkaan kehyksen laadukkaiden ohjelmistojen nopeaan ja luotettavaan toimittamiseen.

Työkokemukseni perusteella selitän, mistä CI/CD-putki koostuu, miten se toimii ja miksi ohjelmistosuunnittelutiimit ovat omaksuneet sen käytännöllisesti ja filosofisesti yhdessä muiden periaatteiden, kuten ketterän testausmenetelmän, kanssa.

Mikä on CI/CD-putki?

CI/CD-putki on läpinäkyvä, automatisoitu ja luotettava ohjelmistojen kehitys- ja toimitusprosessi. CI/CD-toimitusputki koostuu kahdesta erillisestä osasta: jatkuvasta integraatiosta ja jatkuvasta toimituksesta, jotka mahdollistavat ketterän DevOps-työnkulun.

Molemmat osat tukeutuvat voimakkaasti automaatioon virheiden vähentämiseksi ja korkealaatuisen ohjelmistosuunnittelun varmistamiseksi poistamalla raskaat manuaaliset prosessit. Pohjimmiltaan CI/CD-putki tarjoaa sarjan vaiheita automatisoitua ohjelmistojen toimitusta varten.

CI-osuus kannustaa kehittäjiä, ohjelmoijia ja ohjelmistosuunnittelijoita rakentamaan ohjelmistoja kirjoittamalla koodia ja suorittamalla testejä usein. Heitä kannustetaan tarkistamaan koodimuutoksensa ja uuden toiminnallisuutensa säännöllisesti pieninä lähdekoodierinä koodivarastoon.

CD-osuus puolestaan varmistaa, että ohjelmisto-organisaatiolla on aina käyttöönottovalmis ohjelmistotuotos, jonka laatu on jo varmistettu ja joka on validoitu turvatarkistuksilla.

CI/CD-putken neljä päävaihetta

Lähdevaihe

Tämä on putken alku. Se käynnistyy, kun kehittäjä tekee muutoksen koodikantaan. Tyypillisesti näin tapahtuu, kun kehittäjä suorittaa git push- tai git merge-komennon lähettääkseen lähdekoodia versionhallintajärjestelmän koodivarastoon.

Koontivaihe

Koontivaihe on suurelta osin käännösvaihe. Dockerin kaltaisissa mikropalveluihin perustuvissa säilöjärjestelmissä tämä tarkoittaa projektin lähdekoodin ja sen riippuvuuksien niputtamista itsenäisiksi yksiköiksi. Tämän jälkeen ne käännetään, jotta ohjelmistosovelluksesta voidaan rakentaa suoritettava ilmentymä. On kuitenkin huomattava, että käännösvaihe on tarpeen Javan ja C++:n kaltaisilla kielillä. Tulkatuilla kielillä, kuten Pythonilla ja JavaScriptillä, käännös kuitenkin ohitetaan.

Kun ohjelmistotuotos ei läpäise tätä vaihetta, se viittaa usein perustavanlaatuisiin taustalla oleviin ongelmiin, kuten huonoon arkkitehtoniseen konfiguraatioon. Tämä tarkoittaa väistämättä, että ohjelmistoarkkitehtien ja -insinöörien on palattava suunnittelupöydän ääreen ratkaisemaan ongelma.

Testausvaihe

Kuten nimi kertoo, tämä on putken testausvaihe. Tässä CI/CD-putken sisäänrakennettu automaatio osoittaa hyödyllisyytensä säästämällä tiimin aikaa ja vaivaa. Sovelluksen kelvollisuuden ja logiikan arvioimiseksi suoritetaan erilaisia testejä, kuten savutestejä, yksikkötestejä ja integraatiotestejä, automaattisesti.

Käyttöönottovaihe

Käyttöönottovaiheessa testattu ja suoritettava sovelluksen ilmentymä julkaistaan vaadittuun käyttöönottoympäristöön. Organisaatiot ylläpitävät tyypillisesti useita testiympäristöjä eri syistä.

Esimerkiksi alfa-ympäristöissä tehdään käyttäjähyväksyntätestausta sovelluksen virheiden tunnistamiseksi ennen sen julkaisemista tuotteen käyttäjille. Beeta on rajoitettu julkaisu muutamille valituille käyttäjille, minkä jälkeen on yleisölle tarkoitettu tuotantoympäristö. Käyttöönottovaihetta havainnollistaa tarve ylläpitää hyväksyttävää laadunvarmistuksen tasoa.

Mitä jatkuva integraatio (CI) on?

CI tarkoittaa jatkuvaa integraatiota, kun taas CD tarkoittaa jatkuvaa käyttöönottoa. Yhdessä ne varmistavat, että DevOps-tiimeillä on kestävä menetelmä luotettavien ohjelmistojulkaisujen tuottamiseen. Yhdessä ne lyhentävät merkittävästi käyttökelpoisen ohjelmiston ideoinnin, suunnittelun ja tuotantoon viennin välistä aikasykliä. 

Nämä kaksi modernin ohjelmistojen toimitusputken pilaria eivät kuitenkaan ole kolikon kääntöpuolia eivätkä saman ilmiön yin ja yang.

Sekä jatkuva integraatio että jatkuva toimitus ovat riittävän vivahteikkaita ja erilaisia ansaitakseen oman erillisen käsittelynsä ja perusteellisen määritelmänsä.

Miksi CI:tä tarvitaan?

CI:n tehtävänä on tarjota virtaviivainen, luotettava ja automatisoitu prosessi ohjelmistosovellusten kirjoittamiseen, rakentamiseen ja testaamiseen. Prosessina CI keskittyy lähdekoodin rakentamiseen, testaamiseen ja yhdistämiseen projektin koodikantaan useita kertoja päivässä.

CI-prosessin tavoitteena on myös tarjota tasainen ohjelmistotuottavuuden taso. Se saavuttaa tämän edistämällä DevOps-käytäntöjä, jotka kannustavat automatisoituun testaukseen ja uuden koodin tiheään yhdistämiseen keskitettyyn repositorioon.

Kehittäjät tuottavat yleensä säännöllisesti runsaasti lähdekoodia joko uuden toiminnallisuuden rakentamiseksi tai olemassa olevien ominaisuuksien virheiden korjaamiseksi. Ohjelmoijat eivät kuitenkaan yleensä työskentele eristyksissä, vaan he toimivat kehitystiimeissä, joissa yhteistyö muiden koodareiden kanssa on ratkaisevan tärkeää projektin onnistumisen kannalta.

Siksi koodin jättäminen heidän omille tietokoneilleen pitkäksi aikaa haittaa muuta tiimiä. Muun muassa uuden koodin liian myöhäinen integrointi julkaisusyklin aikana saattaa vahingossa rikkoa muuta toiminnallisuutta.

Jatkuvan integraation työkalut maksimoivat käytännön, jossa kehittäjiä kannustetaan yhdistämään koodimuutoksensa tiimin jaettuun repositorioon. Mieluiten useita kertoja päivässä.

Mitä jatkuva toimitus (CD) on?

Kuten edellä mainitsin, jatkuva toimitus tulee jatkuvan integraation jälkeen. Se kattaa prosessit ja infrastruktuurin, jotka tukevat koodimuutosten valmistelua tuotantoympäristöön julkaisemista varten. CD:n yleisenä tavoitteena on varmistaa, että organisaation putkessa on aina rakennettu, testattu, validoitu ja käyttöönottoon valmis ohjelmistotuotos.

CD:n valmisteluun ja käyttöönottoon tarkoitettu infrastruktuuri pyrkii tarjoamaan nopean mutta kestävän ja virheettömän putken ohjelmistokäännösten valmistelemiseksi ja julkaisemiseksi tuotantoon. Sen tavoitteena on myös lyhentää turvatarkistusten suorittamiseen ja ohjelmistotuotosten käyttöönottoon tarvittavaa aikaa.

Miksi CD?

Jatkuvan integraation tavoin CD-työkalut luottavat vahvasti automaatioon ja automatisoituihin testeihin ohjelmistokäännöksen eheyden validoimiseksi ennen sen käyttöönottoa. Prosessin avulla ohjelmistosuunnittelutiimit voivat myös määrittää koodilleen laatutason ennen tuotantoon siirtymistä.

On huomattava, että vaikka jatkuva toimitus on automatisoitu prosessi, tässä putken vaiheessa tarvitaan edelleen manuaalista puuttumista.

Jatkuvan toimituksen ja jatkuvan käyttöönoton ero

Molemmilla, jatkuvalla toimituksella ja jatkuvalla käyttöönotolla, on sama tarkoitus, mutta niiden toteutuksessa on merkittävä ero.

• Jatkuva käyttöönotto: Jokainen koodikantaan yhdistetty koodimuutos otetaan automaattisesti käyttöön tuotannossa. Hyväksyntämekanismia tai manuaalista prosessia ei ole toimimassa varotoimena. Kyseessä on täysin automatisoitu varsinainen käyttöönottoprosessi.
• Jatkuva toimitus on osittain manuaalinen prosessi, mutta se tekee julkaisustrategiasta paljon todennäköisemmin turvallisemman ja kestävämmän.

Miksi CI/CD-putki on tärkeä DevOpsissa?

Nykyisten ohjelmistotoimitusmenetelmien tarpeen ja kehityksen ymmärtämiseksi tarvitaan historiallista näkökulmaa. Ohjelmistosovellusten kehityksen alkuvaiheissa vesiputousmalli oli suosittu.

Tämä yksinkertainen malli käsitteli ohjelmistoprojektia jakamalla sen peräkkäisiin, lineaarisiin vaiheisiin. Siinä noudatettiin jäykkää menetelmää, joka ei sallinut vaiheiden päällekkäisyyttä – yksi vaihe oli saatettava päätökseen ennen seuraavan aloittamista. Lisäksi jokainen vaihe riippui edellisen vaiheen tuotoksista.

Siksi koko mallin toiminta edellytti tiettyä tehtävien erikoistumista. Tämä erikoistuminen pakotti kuitenkin ohjelmistosuunnittelu- ja testaustiimit eriytymään omiin siiloihinsa, jolloin kehittäjät, testaajat ja sivuston luotettavuusinsinöörit työskentelivät usein eristyksissä.

Vesiputousmalli

Vesiputousmalli sopi hyvin aikakauteen, jolloin ohjelmistoyritykset toimittivat tuotteita kuluttajille pakatuilla CD-levyillä ja julkaisupäivät ilmoitettiin julkisesti. Tämä malli soveltuu kuitenkin huonosti nykyaikaan, jossa koodia arvostetaan tuotettavan nopeasti. Tämä pätee erityisesti pilvilaskentaan ja kaikkialla läsnä oleviin palveluna tarjottavan ohjelmiston (SaaS) malleihin, jotka ovat nostaneet loppukäyttäjien odotuksia ohjelmistojen jatkuvasta parantamisesta ja ominaisuuksien jatkuvasta toteuttamisesta.

Monista syistä vesiputousmalli on osoittautunut riittämättömäksi.

Ketteryysmenetelmän kaltaisten parhaiden käytäntöjen ohella nykyaikaiset DevOps-tiimit hyödyntävät CI/CD-putkia toimittaakseen korkealaatuista ja perusteellisesti testattua ohjelmistoa nopeasti ja kestävällä tavalla.

DevOpsin kautta CI/CD tarjoaa käytännöllisen keinon kuroa umpeen ohjelmoijien, käyttötiimien ja muiden ohjelmistokehitys- ja toimitusprosessiin osallistuvien välisiä siiloja.

CI/CD:n periaatteet vähentävät riskejä ja epävarmuutta erityisesti monimutkaisissa projekteissa, joiden on oltava riittävän ketteriä usein muuttuvien vaatimusten huomioimiseksi.

CI/CD-putken käyttöönoton hyödyt

Jotkin CI/CD-putken hyödyt ovat ilmeisiä, kuten ohjelmistoon sisältyvä automaatio, joka vähentää merkittävästi virheille alttiita manuaalisia prosesseja. Tässä on pari muuta CI/CD-putken hyötyä:

• Käyttöönottojen toteuttaminen mahdollisimman vähäisin kitkoin. CI/CD-putki tarjoaa IT-operaattoreille suhteellisen helppokäyttöisen ja yksinkertaisen prosessin, joka vähentää sovellusten rakentamisen ja käyttöönoton monimutkaisuutta. CI/CD:n sisältämä automaatiotoiminnallisuus helpottaa tätä yksinkertaistettua prosessia huomattavasti.
• Toimintojen nopeuden parantaminen. Tuotteen nopeampi iterointi on mahdollista automaation ja nopeampien palautesilmukoiden ansiosta. Automaatio tarjoaa DevOps-teknikoille välittömästi tietoa koontiversion toimivuudesta.
  
  Pienemmät CI-integraatiot ja pienemmät CD-käyttöönotot parantavat DevOps-mittareita, kuten korjaamiseen kuluvaa keskimääräistä aikaa (Mean Time To Resolve, MTTR). MTTR mittaa rikkinäisten ominaisuuksien ja virheiden korjaamiseen kuluvaa keskimääräistä aikaa, mukaan lukien taustalla olevien ongelmien diagnosointi. CI/CD-prosessi kokonaisuudessaan vähentää sovelluksen vianmääritykseen, testaamiseen, rakentamiseen ja käyttöönottoon tarvittavaa aikaa.
• Tuottavuuden lisääminen: Jatkuvan integroinnin pääperiaatteena on kannustaa kehittäjiä yhdistämään koodinsa usein organisaationsa päähaaraan. Tämä lisää todennäköisyyttä, että kaikilla DevOps-tiimin jäsenillä on käytössään uusin toimiva koodi.
  
  Tämä on ratkaisevan tärkeää, sillä koodikannan uusimman version parissa työskentely suojaa kaikkia projektia, sen nykyisiä toimintoja ja ominaisuuksia koskevilta vanhentuneilta oletuksilta. Tämä lisää ohjelmistoprojektien tuottavuutta ja yhteistyötä. Tämä puolestaan lyhentää organisaation tuotteiden markkinoille saattamiseen kuluvaa kokonaisaikaa.
• Julkaisusyklin lyhentäminen sekä mahdollisuus julkaista ohjelmistoa tarpeen mukaan. Digitaalisella aikakaudellamme yritykset tarvitsevat ketteryyttä pysyäkseen elinkelpoisina ja reagoidakseen nopeasti markkinoiden muutoksiin. Teknologiataitavat asiakkaat vaativat yhä useammin kehittyneitä ominaisuuksia, kuten personointia ja edistyksellisiä tekoälytoimintoja.
  
  Muuttuvien aikojen mukana pysymiseksi CI/CD-putket eivät ainoastaan auta organisaatioita nopeuttamaan ohjelmistojen toimitusta markkinoiden muutoksiin vastaamiseksi, vaan myös pitävät niiden ohjelmistovalikoiman aina julkaisukelpoisessa tilassa.
• Mahdollisuus priorisoida ominaisuuksien käyttöönottoja. Toimintojen nopeuttamisen lisäksi CI/CD-infrastruktuuri mahdollistaa sen, että sivustosuunnittelijat voivat painottaa ominaisuuksia, jotka on otettava käyttöön välittömästi tai asetettava muiden edelle.
• Virheiden nopeampi havaitseminen ja ongelmien nopeampi korjaaminen. Koska koodimuutokset integroidaan useammin, CI helpottaa virheiden, ongelmien ja muiden yhteensopimattomuuksien havaitsemista ja korjaamista paljon aikaisemmin ohjelmistokehitysprosessissa. Tämä on erityisen tärkeää sellaisten virheenkorjausten kohdalla, joilla on korkea käyttöönottoprioriteetti, etenkin kun korjataan nollapäivähaavoittuvuuksia.
• Virheiden vähentäminen ja riskien lieventäminen. CI/CD tarjoaa useita suojatoimien ja turvamekanismien kerroksia koko kehityksen elinkaaren ja käyttöönottovaiheiden ajan. Näiden vikasietoisten ja virheiden ennakointiin perustuvien mekanismien yhteisvaikutus vähentää ohjelmistokehitystiimien riskiä tuottaa käyttökelvotonta koodia.
  
  CI/CD-putken sisäänrakennettu automaatio ja automatisoitu testaus kannustavat jatkuvaan testaukseen esimerkiksi yksikkötestauksen, integraatiotestauksen, regressiotestauksen ja muiden vastaavien menetelmien avulla. Lisäksi CI/CD-järjestelmät lähettävät koontivaiheen aikana erilaisia ilmoituksia, jotka hälyttävät IT-johtajat ja sivustosuunnittelijat, kun jokin menee pieleen.
• Laadunvalvonnan parantaminen ja inhimillisten virheiden mahdollisuuksien minimointi. Automaatio poistaa virheille alttiin ihmisen suorittaman puuttumisen tarpeen. CI käynnistää uuden koontiversion aina, kun koodimuutokset yhdistetään keskitettyyn tietovarastoon. Tähän liittyy yleensä yksikkötestejä ja integraatiotestejä, joilla varmistetaan uuden koodin yhteensopivuus järjestelmän kanssa. Tämä suurelta osin kitkaton prosessi on paras käytäntö, joka tuo järjestelmään laadunvalvontaa ja laadunvarmistusta.
• Kokeilujen ja innovoinnin kannustaminen. DevOps-ajattelutapa, jossa koodia tuodaan järjestelmään pieninä kokonaisuuksina, rohkaisee innovointiin. Ensisijaisesti siksi, että prosessi aiheuttaa huomattavasti pienemmän riskialtistuksen, joten tiimeille annetaan enemmän liikkumavaraa kokeilla ja innovoida. Tämä kannustaa startup-yritysten ajattelutapaan ”edetä nopeasti ja rikkoa asioita.”
• Luotettavien julkaisujen luominen. Kuten edellä mainittiin, ohjelmiston julkaiseminen usein mutta pienissä erissä aiheuttaa vähemmän riskejä. Pienempää käyttöönottoa on myös helpompi hallita, erityisesti selvitettäessä, onko järjestelmään tullut virheitä. Useimmissa tapauksissa voi riittää, että tunnistetaan viimeisin käyttöönotto, joka aiheutti virheen. 

Lopuksi

CI/CD-putket ovat olennainen osa nykyaikaista ohjelmistokehitystä ja auttavat tuottamaan korkealaatuisia ohjelmistotuotteita nopeasti kehittyvällä ohjelmistoalalla. 

Jos haluat oppia lisää teknologia-alan ajankohtaisista ja huippuluokan edistysaskelista, tilaa The QA Lead -uutiskirje.