Refaktoroi pipelinet helpottaaksesi siirtymiä työkalujen välillä

Useimmiten projektin ja sitä buildaavien ja testaavien putkien kasvaessa tiimit joutuvat käyttämään yhä enemmän aikaa niiden ylläpitoon. Tämän seurauksena CI/CD on ainoa tapa buildata ja testata ohjelmistoa, koska se toimii vain yhdellä koneella.

Jos CI/CD-työkalusi siis lakkaavat toimimasta, seuraukset voivat olla tiimillesi katastrofaaliset: ilman työkaluja kaikki kehitystyö pysähtyy kuin seinään. Vaikkei näin koskaan kävisikään, siirtyminen uudempiin ja edistyneempiin työkaluihin on vaikeaa – ehkä jopa mahdotonta. Ja tarvitseeko edes perustella, miksi paremmat työkalut ovat aina toivottavia?

Tässä blogissa annan vinkkejä siihen, miten vältät ”toimii minun koneellani” -ongelman ja voit hyödyntää tulevaisuudessa uusia CI/CD-työkaluja.

Kontita jokainen vaihe

Lyhyesti sanottuna kontitus pakottaa miettimään syöteparametreja ja haluttua lopputulosta. CI/CD:ssä kontitettujen vaiheiden ajatteleminen vastaa sitä, miten ohjelmointifunktioita käytetään.

Jokaisen vaiheen kontittamisesta on useita hyötyjä:

1. Versioiden hallinta helpottuu, kun näet jokaisen vaiheen kehityshistorian ja voit käyttää saman asian eri versioita eri yhteyksissä, kuten projekteissa.

2. Kontitus yksinkertaistaa testausta ja virheenkorjausta, sillä putkessa ilmenevän ongelman voi helposti toistaa ajamalla kontin kehityskoneella.

3. Suosittu kontitustyökalu Docker kannustaa luomaan kevyitä kontteja eli vaiheita, mikä takaa erittäin nopean suorituskyvyn.

4. Jos kokonaisuus on hyvin modularisoitu, eri vaiheet voidaan myös ajaa rinnakkain. Lisätietoja saat suunnatusta syklittömästä graafista (DAG).

Konttien sisäinen logiikka voi olla monimutkaista – palaan siihen myöhemmin – mutta kontin ulkopuolisiin asioihin ”koskevan” logiikan tulisi aina pysyä yksinkertaisena. Tämä on hyvä käytäntö kaikessa kehitystyössä.

Jaa ne organisaatiossasi kolmannen osapuolen työkalulla

Organisaation kaikkien kontitettujen CI/CD-vaiheiden tallentaminen yhteen repositorioon parantaa löydettävyyttä ja uudelleenkäyttöä. Tiimien ei tarvitse tehdä ylimääräistä työtä, jos vaiheet ovat jo valmiina. Samalla yhteistyö paranee koko organisaatiossa.

Vaikka CI/CD lakkaisi toimimasta, voit muutamalla docker pull -komennolla ajaa samat vaiheet kuin CI/CD:ssä. Työsi ei siis keskeydy missään vaiheessa.

Kapseloi monimutkainen logiikka tehtävätyökaluilla

Bash on hyvä, mutta se on 50 vuotta vanha ohjelmointikieli, joka alkaa näyttää ikänsä. Käytössämme on myös uudempia ja modernimpia ohjelmointikieliä, joita hyödynnämme jo projekteissamme monimutkaisen logiikan toteuttamiseen. Ollaan rehellisiä: kaikki väittävät osaavansa bashia, mutta eivät oikeasti osaa – minä mukaan lukien.

Siksi build-putkissa tarvittava monimutkainen logiikka – eli muu kuin yksinkertainen if-else-haaroittelu – kannattaa kirjoittaa näillä työkaluilla projektisi ohjelmointikielellä, jonka jo osaat.

Jokaisella kielellä on oma tehtävätyökalunsa. Huomionarvoisia esimerkkejä ovat:

• NPM Nodella

• Invoke Pythonilla

• Rake Rubylla

• Maven Javalla

• Bazel C:llä

Käytä näitä tehtävätyökaluja konteissasi bash-skriptien kirjoittamisen sijaan. Näin voit hyödyntää muita ohjelmistokehityksen parhaita käytäntöjä, kuten yksikkötestausta, ja varmistaa logiikan toimivuuden kaikissa tilanteissa – ilman kontekstin vaihtamista ”varsinaisen” koodin ja CI/CD-koodin välillä.

Salaisuudet ja ympäristömuuttujat CI/CD:n ulkopuolella

Salaisuuksien ja ympäristömuuttujien määrä kasvaa projektin elinkaaren aikana, mikä lisää sen monimutkaisuutta. Siksi ne kannattaa jakaa kahteen erilliseen luokkaan:

Build-aikaiset: Näitä tarvitaan CI/CD-prosessin aikana, jotta projekti voidaan paketoida käyttökelpoisiksi artefakteiksi. Niiden määrä kannattaa aina pyrkiä minimoimaan, mutta niistä ei koskaan pääse täysin eroon.

Ajonaikaiset: Näitä tarvitaan sovelluksen käynnistyessä tai sen ollessa käynnissä. Niitä on paljon, ja ne lisätään usein CI/CD:hen, vaikka ne palvelisivat paremmin tarkoitustaan muualla. Esimerkiksi tietokantayhteyden tunnistetiedot ja URL-osoitteet sisällytetään usein CI/CD:hen. Mutta entä jos niitä pitää muuttaa, kun ohjelmisto on jo tuotannossa? Jos ne ovat CI/CD:ssä, on tehtävä uusi julkaisu. Se on hankalampaa kuin niiden muokkaaminen kolmannen osapuolen järjestelmässä, kuten HashiCorp Vaultissa. Kun ne poistetaan yhtälöstä, CI/CD:n häiriöiden vaikutus pienenee.

Lopuksi

Kun toteutat kaikki edellä luettelemani vaiheet, olet hyvällä tiellä kohti nopeampaa CI/CD:tä, joka tekee kaikesta sujuvampaa. Tietenkin tämä on helpommin sanottu kuin tehty. Ainakaan nämä vaiheet eivät kuitenkaan kuulostaneet liian pelottavilta!