Mikä on CI/CD? Jatkuva integrointi ja toimitus selitettynä yksinkertaisesti

CI/CD on tapa toimittaa ohjelmistoja: jokainen koodimuutos rakennetaan, testataan automaattisesti ja – jos se läpäisee testit – valmistellaan julkaisua varten tai julkaistaan. CI (jatkuva integrointi) tarkoittaa, että muutoksia yhdistetään usein ja automaattiset testit tarkistavat ne joka kerta. CD (jatkuva toimitus tai julkaisu) tarkoittaa, että läpäisseet muutokset paketoidaan ja viedään kohti käyttäjiäsi vähällä tai ilman manuaalista työtä.

Idea on yksinkertainen: virheet havaitaan minuuteissa niiden tekemisestä, ei viikkoja myöhemmin, kun asiakas löytää ne.

Miksi CI/CD on tärkeä, kun rakennat tekoälyllä

Tekoälyrakentajat tekevät koodimuutoksia nopeasti. Yksi kehote voi koskettaa kymmentä tiedostoa. Nopeus on hienoa, kunnes muutos kassasivulle rikkoo hiljaa kirjautumissivun eikä kukaan huomaa sitä, ennen kuin käyttäjä kirjoittaa sinulle.

CI/CD on juuri tähän turvaverkko. Sen sijaan että luottaisit siihen, että jokainen muutos on kunnossa, putki ajaa samat tarkistukset joka kerta:

• Rakentuuko sovellus yhä ilman virheitä?
• Menevätkö automaattiset testit yhä läpi?
• Noudattaako koodi projektin sääntöjä (tyypit, muotoilu, tietoturvatarkistukset)?

Jos mikä tahansa tarkistus epäonnistuu, muutos pysäytetään ennen kuin se pääsee käyttäjille. Mitä nopeammin koodisi muuttuu, sitä arvokkaammaksi käy tarkistus, joka ei väsy eikä ohita vaihetta.

Arkinen vertauskuva

Ajattele leipomoa, joka myy leipää kaupoille joka aamu.

• Ilman CI/CD:tä jokainen leipuri säätää omaa reseptiään viikon ajan, sitten kaikki yhdistävät muutoksensa perjantai-iltana ja toivovat leivän nousevan. Kun se ei nouse, kukaan ei tiedä, kenen muutos aiheutti sen.
• CI:n kanssa jokainen pieni reseptimuutos leivotaan heti koeleiväksi ja tarkistetaan – maku, paino, muoto. Huono muutos havaitaan samana päivänä, ja tiedät tarkalleen, mikä se oli.
• CD:n kanssa tarkastuksen läpäisseet leivät menevät suoraan jakeluautoon, paketoituna ja merkittynä joka kerta samalla tavalla, sen sijaan että joku pakkaisi laatikoita käsin kello viideltä aamulla.

Tarkastus ei tee leipureista parempia. Se tekee heidän virheistään halpoja.

Miten CI/CD-putki toimii

Putki (pipeline) on lista vaiheita, jotka CI/CD-palvelu ajaa automaattisesti, kun jotakin tapahtuu – yleensä kun joku työntää koodia repositorioon, kuten GitHubiin. Tyypillinen putki näyttää tältä:

Jokainen vaihe ajetaan puhtaalla koneella, ei kenenkään kannettavalla, joten ”minulla toimii” ei enää kelpaa selitykseksi. Jos vaihe epäonnistuu, putki pysähtyy ja kertoo muutoksen tehneelle.

Vaiheet on määritelty koodin mukana kulkevassa konfiguraatiotiedostossa. Esimerkiksi GitHub Actionsissa se on YAML-tiedosto repositorion kansiossa .github/workflows.

Jatkuva toimitus vs jatkuva julkaisu

”CD” on epäselvä, ja ihmiset käyttävät sitä molemmilla tavoilla:

Jatkuva julkaisu toimii hyvin vain, jos testit ovat kunnossa. Jos testit eivät kata kassaa, jatkuva julkaisu toimittaa iloisesti rikkinäisen kassan.

Esimerkki käytännössä: varaussovellus putkella

Oletetaan, että sinulla on kampaamon varaussovellus ja sen koodi on GitHub-repositoriossa. Pyydät tekoälyrakentajalta: ”Lisää 10 % alennus ensikertaa asioiville asiakkaille.”

1. Muutos työnnetään uuteen haaraan ja avataan vetopyyntö (pull request).
2. Putki käynnistyy. Se asentaa paketit ja rakentaa sovelluksen – tämä läpäisee.
3. Se ajaa testit. Yksi testi, ”palaava asiakas maksaa täyden hinnan”, epäonnistuu: alennus koskee kaikkia.
4. Vetopyynnössä näkyy punainen rasti. Muutosta ei voi yhdistää.
5. Pyydät tekoälyä korjaamaan sen. Se työntää korjauksen; putki ajetaan uudelleen, ja kaikki menee läpi.
6. Muutos yhdistetään. Putki julkaisee sen testiympäristöön, jossa kokeilet testivarausta.
7. Hyväksyt, ja se julkaistaan tuotantoon.

Ilman putkea vaiheen 3 virhe olisi mennyt asiakkaidesi lompakoihin.

Keskeiset termit

Yleisiä väärinkäsityksiä

• ”CI/CD tarkoittaa, että sovellukseni on testattu.” Putki ajaa vain ne testit, jotka sinulla on. Jos testejä ei ole, CI todistaa vain, että sovellus rakentuu – ei mitään muuta. Pyydä tekoälyä kirjoittamaan testit tärkeimmille kuluille.
• ”CI/CD on vain suurille yrityksille.” Hallitut työkalut kuten GitHub Actions vaativat lyhyen konfiguraatiotiedoston pystyttämiseen, ja pienet tiimit käyttävät niitä jatkuvasti. Työtä vaatii testit, ei työkalut.
• ”Automaattinen julkaisu tarkoittaa, ettei kukaan tarkista mitään.” Hyvät putket lisäävät tarkistuksia, eivät poista niitä. Monet tiimit pitävät ihmisen hyväksyntävaiheen ennen tuotantoa.
• ”Jos putki on vihreä, sovellus toimii.” Se tarkoittaa, että automaattiset tarkistukset menivät läpi. Sinun pitäisi silti kokeilla muutosta itse, mieluiten esikatselussa tai testiympäristössä.
• ”CI/CD korvaa varmuuskopiot.” Ei korvaa. Huono tietokantamigraatio, joka menee testien läpi, voi silti vahingoittaa oikeaa dataa. Pidä varmuuskopiot ja tapa palauttaa.

Mitä pyytää tekoälyrakentajaltasi

• ”Kirjoita automaattiset testit rekisteröitymiselle, kirjautumiselle ja kassalle, ja näytä, miten ne ajetaan.”
• ”Aseta GitHub Actions -työnkulku, joka asentaa riippuvuudet, rakentaa sovelluksen ja ajaa testit jokaiselle vetopyynnölle.”
• ”Lisää putkeen tyyppitarkistus ja lintteri, ja anna sen epäonnistua virheissä.”
• ”Selitä selkokielellä, mitä putken jokainen vaihe tekee.”
• ”Mitä tapahtuu, jos julkaisu epäonnistuu puolivälissä? Miten palaan takaisin?”
• ”Tarkista, ettei repositoriossa tai putken lokeissa ole kovakoodattuja salaisuuksia.”

Jos sovelluksesi käyttää API-avaimia, putkikin tarvitsee niitä – tallennettuna salattuina salaisuuksina CI-työkaluun, ei koskaan konfiguraatiotiedostoon. Katso ympäristömuuttujat ja salaisuudet.

CI/CD ja Mythex

Mythex ei aja CI-putkea puolestasi, mutta se kattaa useita samoja tarpeita omalla tavallaan:

• Tarkistuspisteet. Jokaisen onnistuneen agenttivuoron jälkeen Mythex tallentaa git-tarkistuspisteen, ja Palauta tähän kohtaan palauttaa projektin, jos muutos meni pieleen. Katso Chat.
• Sovellustestaus. Kirjoita /test, ja agentti klikkaa live-esikatselusi läpi kuin käyttäjä ja raportoi rikkinäiset kulut – hyödyllinen ennen jokaista julkaisua. Katso Sovellustestaus.
• Julkaiseminen on tarkoituksellinen vaihe. Muutokset näkyvät ensin yksityisessä esikatselussa; julkinen sovelluksesi päivittyy vasta, kun julkaiset uudelleen. Tämä on lähempänä jatkuvaa toimitusta kuin jatkuvaa julkaisua.
• GitHub-synkronointi (Pro). Synkronoi projekti GitHub-repositorioon, niin voit lisätä omat GitHub Actions -työnkulut ajamaan testit jokaisella työnnöllä. Katso GitHub ja vienti.

Siitä, mitä kannattaa testata käsin ennen julkaisua, saat listan sivulta kuinka testata sovelluksesi ennen julkaisua, ja versionhallintaan liittyen sivulta kuinka käyttää Gitiä tekoälyllä rakennetun sovelluksen kanssa.

Kysymykset