Ett första intryck av GitHub Actions CI/CD

Det är ett tydligt svar på att andra leverantörer har lanserat liknande verktyg. I det här inlägget ger jag ett första intryck baserat på skrivbordsundersökningar och praktiska tester. Jag har inte jämfört GitHub Actions med dess potentiella konkurrenter.

Introduktion till GitHub Actions

Jag tyckte att det var enkelt att komma i gång med Actions eftersom jag känner till olika CI-system, som Travis CI och CircleCI. Gemensamt för dem är märkspråket YAML. GitHub Actions har stöd för de tre stora operativsystemen Windows, MacOS och Linux, och du kan köra alla programmeringsspråk som stöds av dessa.

Utöver att triggas av pull requests och commits kan Actions reagera på alla GitHub-händelser. Du kan trigga specifika GitHub Actions-workflows, inklusive open source-actions, baserat på:

• skapandet av ärenden

• kommentarer

• att en ny medlem ansluter till repositoryt

• ändringar i GitHub-projektpanelen.

Actions har en hög integrationsnivå med GitHub, vilket eliminerar behovet av en ytterligare CI-leverantör. Ur ett affärsperspektiv är det ett tydligt svar på GitLab och deras CI-erbjudande samt Azure DevOps.

Syntax

I koden nedan visar jag ett workflow som är konfigurerat att triggas vid ”push”, det vill säga varje commit av kod till vårt repository. Vårt specifika workflow konfigurerar Golang och dess beroenden och kör sedan den binära filen, som skriver ut ”Hello World!”.

Actions har live-streamade loggar under builds, vilket ger direkt återkoppling med färgkodning och möjlighet att fälla ihop kod för bättre överblick.

Loggar från workflow-körningar kan visas live, som nedan. Just den här utdata kommer från ett workflow med ett jobb som konfigurerar Go, hämtar och installerar Golang-beroenden och sedan kör filen run.go. Den innehåller kod som skriver ut ”Hello, World!”.

Kodexemplet ovan är hämtat från mitt GitHub-konto.

Workflows från communityn

Offentligt tillgängliga workflows, så kallade community-powered workflows, skapas av GitHubs stora community och möjliggör återanvändbara workflows. Communityns insatser resulterar i högkvalitativ kod som har testats och granskats av en bredare community och publicerats på GitHub Marketplace.

En betydande positiv bieffekt är att workflowet optimeras kontinuerligt.

Listan över actions växer snabbt. Det kan spara mycket tid i mjukvaruutvecklingen eftersom utvecklare slipper uppfinna hjulet på nytt varje gång. Det finns också en fristående community, oberoende av GitHub, för delade GitHub Actions. Den har vuxit stadigt i takt med att utvecklare har visat intresse för delade workflows.

Både GitHub Marketplace och den Netlify-baserade communityn för delning av workflows är offentliga, så alla kan bidra till och använda actions. Organisationer som vill dela workflows privat behöver göra det via egna repositories på GitHub.

Repositoryt får då en knapp med texten ”Include action in your project”, som gör att du enkelt kan lägga till actionen i valfritt repository. Workflows kan alltså delas både offentligt och privat.

Beständig lagring av workflowdata med artifacts

GitHub Actions har stöd för beständig lagring av workflowdata med artifacts. Ett workflow som innehåller flera jobb kan lagra och bearbeta data från tidigare jobb. Det gör att utvecklare kan optimera workflows och skriva renare och effektivare kod.

I koden nedan visar jag detta med ett exempel. Workflowet består av tre jobb som är beroende av varandra och visar möjligheten att återanvända kod.

Artifactet kan laddas ned när workflow-körningen har slutförts. I det här fallet är det en .txt-fil som innehåller strängen ”Hello World!”, som skrevs ut i shell till stdout med hjälp av två separata jobb och sparades i artifact-filen under respektive jobb.

Nackdelen är att det inte går att hämta enbart detta artifact via GitHub API. API:t låter dig bara ladda ned hela arkivutdata. Artifact-funktionen fungerar på olika operativsystem, vilket exemplet visar.

Jobb körs parallellt som standard. I det här fallet definierade jag beroenden till andra jobb, vilket gjorde körningen sekventiell.

Cachelagring av beroenden och build-resultat

GitHub släppte nyligen funktionalitet för cachelagring av beroenden och build-resultat i syfte att förbättra exekveringstiden för workflows.

När ett jobb körs exekveras det i en ren miljö där alla beroenden och nödvändiga paket laddas ned. Under utvecklingen kan detta vara en tidskrävande process när du driftsätter dina projekt. Genom att använda cachefunktionen kan du undvika flaskhalsen som uppstår när stora mängder data ständigt laddas ned. Vid första anblick låter detta mycket likt föregående avsnitt om beständig lagring av workflowdata, och det stämmer precis.

Skillnaden är att användningsområdet för cachelagring av beroenden skiljer sig åt. Den är avsedd för filer som inte ändras kontinuerligt i jobb, vilket gör beroenden till ett bra användningsområde. Beständig lagring av workflowdata passar bättre för data som ändras kontinuerligt i flera jobb i workflowet.

Cachelagring konfigureras i YAML-filen genom att definiera följande:

• ‘path’, som är en katalog där cachen lagras.

• ‘key’, som är en unik nyckel för att återställa och spara cachen.

• ‘restore keys’: en lista med andra nycklar att prova om den första nyckeln inte ger en träff.

Nyckeln används för att identifiera den specifika cachen och möjliggör återanvändning när en ‘cache-hit’ identifieras. Om en ‘cache-miss’ identifieras ignoreras instruktionen. Modellen liknar CircleCI:s cachefunktion, som använder keys och restore_keys/caches.

Johan Abildskov, DevOps Engineer på Eficode Praqma, har skrivit ett exempel på cachelagring med Actions som är väl värt att titta på.

Egenskaper för workflows

Manuell start av workflowkörningar saknas fortfarande. Det är möjligt via GitHub API, men är inte optimalt ur ett driftsperspektiv eller för Developer Experience i CI/CD-system.

Den här saknade funktionaliteten försvårar felsökning och kan försämra användarupplevelsen för utvecklare. När builden är klar kan build-resultatet laddas ned från GitHub Actions-sidan.

Matrix builds

Om ditt team bygger mjukvara för fler än en version av ett språk, operativsystem eller verktyg som stöds, låter GitHub Actions dig köra dessa variationer genom Matrix builds.

Varje konfiguration i matrisen är en kopia av jobbet som körs och rapporterar en status.

I kodexemplet på nästa sida har jag visat en matrix build. På raden ‘runs-on’ läser jag värdena i listan ‘matrix-os’ genom att iterera över dess array, som innehåller referenser till fyra operativsystem: två Ubuntu-versioner, macOS och Windows.

Det innebär att fyra jobb av `job_1` körs. Varje körning sker på ett annat operativsystem och skapar egna loggar samt exakt samma resultat, eftersom jag har angett det i min workflowfil.

Funktionen för matrix builds kommer sannolikt att användas flitigt av utvecklare som arbetar med DevOps/NoOps, och den sparar mycket tid när utvecklingsworkflows skapas.

Self-hosted runners

GitHub Actions låter dig köra workflows på deras servrar eller på dina egna servrar med funktionen self-hosted runners.

Prismodell

Actions är helt kostnadsfritt för publika repositories. För privata repositories gäller en ’betala per minut’-modell. Det är mer än till exempel CircleCI erbjuder i sitt kostnadsfria abonnemang.

Slutsats

GitHub Actions har fått stor uppmärksamhet i GitHub-communityn. Det kräver minimal konfiguration: med en enkel knapp på sidan för dina GitHub-repositories startar du konfigurationen av en CI/CD-pipeline. Det gör att utvecklaren kan fokusera på utveckling i stället för att till exempel sätta upp servrar för Jenkins eller registrera sig hos andra leverantörer som CircleCI.

Det har kommit få officiella kommentarer om funktioner under utveckling, både under betan och efter lanseringen. Det gör det svårt att bedöma deras go-to-market-strategi. GitHubs satsning på CI-funktionalitet är betydande med tanke på den stora community som redan använder GitHub, och ett ganska naturligt steg eftersom konkurrenter som GitLab har haft den här möjligheten ett tag, samtidigt som automatisering blir allt viktigare.

När detta skrivs släpptes Actions i full version för bara ett par dagar sedan och har ännu inte bevisats i branschen. Även om det är ett lovande och välkommet steg för utvecklare kan det vara klokt att vänta ett tag innan du kör produktionsarbetslaster.