Ensivaikutelma GitHub Actionsin CI/CD:stä

Tämä on selkeä vastaus siihen, että muut toimittajat ovat tuoneet markkinoille vastaavia työkaluja. Tässä kirjoituksessa jaan ensivaikutelmani, jotka perustuvat taustatutkimukseen ja käytännön testaukseen. En ole verrannut GitHub Actionsia sen mahdollisiin kilpailijoihin.

GitHub Actions esittelyssä

Actions oli helppo omaksua, sillä tunnen erilaisia CI-järjestelmiä, kuten Travis CI:n ja CircleCI:n. Niitä yhdistää YAML-merkintäkieli. GitHub Actions tukee kolmea suurta käyttöjärjestelmää: Windowsia, macOS:ää ja Linuxia. Voit käyttää mitä tahansa näiden tukemaa ohjelmointikieltä.

Pull requestien ja committien lisäksi Actionsilla voi reagoida mihin tahansa GitHub-tapahtumaan. Voit käynnistää tiettyjä GitHub Actions -työnkulkuja, myös open source -työnkulkuja, seuraavien tapahtumien perusteella:

• issueiden luominen

• kommentit

• uuden jäsenen liittyminen repositorioon

• muutokset GitHubin projektitaulussa.

Actions integroituu vahvasti GitHubiin, joten erillistä CI-toimittajaa ei tarvita. Liiketoiminnan näkökulmasta se on selkeä vastaus GitLabin CI-tarjontaan ja Azure DevOpsiin.

Syntaksi

Alla olevassa koodissa esittelen työnkulun, joka käynnistyy push-tapahtumasta eli jokaisesta repositorioon tehtävästä koodicommitista. Työnkulkumme määrittää Golangin ja sen riippuvuudet, minkä jälkeen se suorittaa binääritiedoston, joka tulostaa “Hello World!” -tekstin.

Actions tarjoaa buildien aikana reaaliaikaisesti päivittyvät lokit, jotka antavat välitöntä palautetta. Selkeyttä tuovat värikoodaus ja mahdollisuus piilottaa koodiosioita.

Työnkulkuajon lokit voi nähdä reaaliaikaisesti, kuten alla. Tämä tuloste on työnkulusta, jossa on yksi jobi: se määrittää Gon, hakee ja asentaa Golang-riippuvuudet ja suorittaa sitten run.go-tiedoston. Tiedosto sisältää koodin, joka tulostaa “Hello, World!” -tekstin.

Yllä oleva koodiesimerkki on GitHub-tililtäni.

Yhteisön kehittämät työnkulut

GitHubin laaja yhteisö luo julkisesti saatavilla olevia työnkulkuja, joita kutsutaan yhteisön kehittämiksi työnkuluiksi. Ne mahdollistavat työnkulkujen uudelleenkäytön. Yhteisön työ tuottaa laadukasta koodia, jonka laajempi yhteisö on testannut ja arvioinut ja joka julkaistaan GitHub Marketplacessa.

Merkittävä myönteinen sivuvaikutus on, että työnkulkua optimoidaan jatkuvasti.

Toimintojen valikoima kasvaa nopeasti. Tämä voi säästää merkittävästi ohjelmistokehityksen aikaa, sillä kehittäjien ei tarvitse keksiä pyörää uudelleen joka kerta. GitHubista riippumaton yhteisö jakaa myös GitHub Actions -toimintoja, ja se on kasvanut tasaisesti kehittäjien kiinnostuessa jaetuista työnkuluista.

Sekä GitHub Marketplace että Netlify-pohjainen työnkulkujen jakamisyhteisö ovat julkisia, joten kaikki voivat osallistua ja hyödyntää toimintoja. Organisaatioiden, jotka haluavat jakaa työnkulkuja yksityisesti, on jaettava ne itse luomiensa GitHub-repositorioden kautta.

Repositoriossa on tällöin ”Include action in your project” -painike, jonka avulla voit lisätä toiminnon helposti valitsemaasi repositorioon. Työnkulkuja voi siis jakaa sekä julkisesti että yksityisesti.

Työnkulkudatan säilyttäminen artifactien avulla

GitHub Actions tukee työnkulkudatan säilyttämistä artifactien avulla. Useita jobeja sisältävä työnkulku voi säilyttää ja käsitellä aiempien jobien dataa. Tämä auttaa kehittäjiä optimoimaan työnkulkuja ja kirjoittamaan selkeämpää ja tehokkaampaa koodia.

Alla oleva koodi havainnollistaa tätä esimerkin avulla. Työnkulku koostuu kolmesta toisistaan riippuvasta jobista ja osoittaa, miten koodia voidaan käyttää uudelleen.

Artifactin voi ladata työnkulkuajon päätyttyä. Tässä tapauksessa se on .txt-tiedosto, joka sisältää merkkijonon “Hello World!”. Se tulostettiin shellissä stdoutiin kahdella erillisellä jobilla ja tallennettiin artifact-tiedostoon kummankin jobin aikana.

Haittapuolena on, ettei artifactia voi hakea yksinään GitHub API:n kautta: API mahdollistaa vain koko arkistotulosteen lataamisen. Artifactien toiminnallisuus toimii eri käyttöjärjestelmissä, kuten esimerkki osoittaa.

Työt suoritetaan oletuksena rinnakkain. Tässä tapauksessa määrittelin riippuvuuksia muista töistä, jolloin suoritus etenee peräkkäin.

Riippuvuuksien ja build-tulosteiden välimuistiin tallentaminen

GitHub julkaisi hiljattain toiminnon riippuvuuksien ja build-tulosteiden välimuistiin tallentamiseen työnkulkujen suoritusajan parantamiseksi.

Kun työ suoritetaan, se ajetaan puhtaassa ympäristössä, johon kaikki riippuvuudet ja tarvittavat paketit ladataan. Tämä voi viedä kehityksen aikana paljon aikaa, kun otat projektejasi käyttöön. Suurten tietomäärien jatkuvasta lataamisesta syntyvä pullonkaula kannattaa välttää hyödyntämällä välimuistiominaisuutta. Ensi silmäyksellä tämä kuulostaa hyvin samankaltaiselta kuin edellinen osio työnkulun datan säilyttämisestä – ja sitä se onkin.

Erona on riippuvuuksien välimuistiin tallentamisen käyttötarkoitus: se on tarkoitettu tiedostoille, joita töissä ei muokata jatkuvasti, joten riippuvuudet ovat hyvä käyttökohde. Työnkulun datan säilyttäminen sopii paremmin dataan, jota muokataan jatkuvasti useissa työnkulun töissä.

Välimuisti määritetään YAML-tiedostossa seuraavasti:

• ‘path’, eli hakemisto, johon välimuisti tallennetaan.

• ‘key’, eli yksilöllinen avain välimuistin palauttamiseen ja tallentamiseen.

• ‘restore keys’, eli luettelo muista avaimista, joita kokeillaan, jos ensimmäisellä avaimella ei löydy osumaa.

Avainta käytetään kyseisen välimuistin tunnistamiseen, jolloin sitä voidaan käyttää uudelleen, kun ‘cache-hit’ tunnistetaan. Jos tunnistetaan ‘cache-miss’, ohje jätetään huomiotta. Sen malli muistuttaa CircleCI:n välimuistiominaisuutta, jossa käytetään key- ja restore_keys/cache-arvoja.

Johan Abildskov, DevOps Engineer Eficode Praqmassa, kirjoitti Actionsin välimuistiin tallentamisesta esimerkin, johon kannattaa tutustua.

Työnkulun ominaisuudet

Työnkulkujen suoritusten manuaalinen käynnistäminen puuttuu toistaiseksi. Se on mahdollista GitHub API:n kautta, mutta se ei ole ihanteellinen ratkaisu CI/CD-järjestelmien käytön ja kehittäjäkokemuksen kannalta.

Tämän toiminnon puute hankaloittaa debuggausta ja voi heikentää kehittäjien käyttäjäkokemusta. Kun build on valmis, build-tulosteen voi ladata GitHub Actions -sivulta.

Matrix-buildit

Jos tiimisi kehittää ohjelmistoa useammalla kuin yhdellä tuetulla ohjelmointikielen, käyttöjärjestelmän tai työkalun versiolla, GitHub Actions mahdollistaa näiden variaatioiden ajamisen Matrix-buildien avulla.

Jokainen matriisin konfiguraatio on kopio työstä, joka suoritetaan ja josta raportoidaan tila.

Seuraavan sivun koodiesimerkissä esittelen matrix-buildin. Rivillä ‘runs-on’ luen ‘matrix-os’-luettelon arvot käymällä läpi sen taulukon, joka sisältää viittaukset neljään käyttöjärjestelmään: kahteen Ubuntu-versioon, macOS:ään ja Windowsiin.

Tämä tarkoittaa, että `job_1`-työstä luodaan neljä työtä. Kukin suoritus ajetaan eri käyttöjärjestelmällä, ja se tuottaa omat lokinsa sekä täsmälleen saman tulosteen, koska määrittelin niin työnkulun tiedostossa.

Matrix-build-ominaisuus tulee todennäköisesti olemaan DevOpsia/NoOpsia hyödyntävien kehittäjien ahkerassa käytössä, ja se säästää paljon aikaa kehitystyönkulkujen luomisessa.

Itsehallinnoidut runnerit

GitHub Actions mahdollistaa työnkulkujen ajamisen GitHubin palvelimilla tai omilla palvelimillasi self-hosted runners -ominaisuuden avulla.

Hinnoittelumalli

Actions on täysin maksuton julkisille repositorioille. Yksityisissä repositorioissa käytetään minuuttiperusteista ‘pay as you go’ -mallia. Tämä on enemmän kuin esimerkiksi CircleCI tarjoaa maksuttomalla tasollaan.

Yhteenveto

GitHub Actions on herättänyt laajaa kiinnostusta GitHub-yhteisössä. Sen käyttöönotto vaatii vain vähän konfigurointia: GitHub-repositoriosi sivulla oleva yksinkertainen painike käynnistää CI/CD-putken konfiguroinnin. Näin kehittäjä voi keskittyä kehitystyöhön sen sijaan, että asentaisi esimerkiksi Jenkins-palvelimia tai rekisteröityisi muiden palveluntarjoajien, kuten CircleCI:n, käyttäjäksi.

Kehitteillä olevista toiminnallisuuksista on kerrottu virallisesti vain vähän niin betavaiheessa kuin julkaisun jälkeenkin. Siksi niiden markkinoillepääsystrategiaa on vaikea arvioida. GitHubin siirtyminen tarjoamaan CI-toiminnallisuuksia on merkittävä asia, kun otetaan huomioon GitHubia jo käyttävä suuri yhteisö. Se on myös luonteva askel, sillä GitLabin kaltaisilla kilpailijoilla tämä kyvykkyys on ollut jo jonkin aikaa, ja automaation merkitys kasvaa jatkuvasti.

Kirjoitushetkellä Actions oli ollut täysin julkaistuna vasta muutaman päivän, eikä sitä ole vielä testattu käytännössä laajasti alalla. Vaikka se on kehittäjille lupaava ja tervetullut uudistus, tuotantotyökuormien ajamista kannattaa ehkä odottaa vielä jonkin aikaa.