Hur använder jag GitHub Actions för att skapa arbetsflöden för CI?

Slutförd

Kom ihåg att målet är att automatisera kodgenererings- och publiceringsprocessen så att funktionerna uppdateras varje gång en utvecklare lägger till en ändring i kodbasen.

Om du vill implementera den här processen lär du dig att:

• Skapa ett arbetsflöde från en mall.
• Undvik duplicering med hjälp av återanvändbara arbetsflöden.
• Testa mot flera mål.
• Separera bygg- och testjobb.

Skapa ett arbetsflöde från en mall

För att skapa ett arbetsflöde är det vanligt att börja med en mall. En mall har vanliga jobb och steg förkonfigurerade för den specifika typ av automatisering som du implementerar. Om du inte är bekant med arbetsflöden, jobb och steg kan du läsa modulen Automatisera utvecklingsuppgifter med hjälp av GitHub Actions .

På huvudsidan för din GitHub-lagringsplats väljer du Åtgärder och sedan Nytt arbetsflöde.

På sidan Välj ett arbetsflöde kan du välja mellan många typer av mallar. Ett exempel är mallen Node.js. Node.js-mallen installerar Node.js och alla beroenden, skapar källkoden och kör tester för olika versioner av Node.js. Ett annat exempel är Python-paketmallen , som installerar Python och dess beroenden och sedan kör tester, inklusive lint, i flera versioner av Python.

Börja med mallen Node.js arbetsflöde genom att i sökrutan ange Node.js.

I sökresultatet går du till fönstret Node.js och väljer Konfigurera.

En node.js.yml fil för projektet skapas från mallen:

name: Node.js CI

on:
  push:
    branches: [ "main" ]
  pull_request:
    branches: [ "main" ]

jobs:
  build:

    runs-on: ubuntu-latest

    strategy:
      matrix:
        node-version: [14.x, 16.x, 18.x]

    steps:
    - uses: actions/checkout@v3
    - name: Use Node.js ${{ matrix.node-version }}
      uses: actions/setup-node@v3
      with:
        node-version: ${{ matrix.node-version }}
        cache: 'npm'
    - run: npm ci
    - run: npm run build --if-present
    - run: npm test

Som du ser i on attributet körs det här exempelarbetsflödet som svar på antingen en push-överföring till lagringsplatsen eller när en pull-begäran skapas mot huvudgrenen.

Det här arbetsflödet kör ett jobb, vilket anges av attributet job .

Attributet runs-on anger att arbetsflödet för operativsystemet körs på ubuntu-latest. Attributet node-version anger att det finns tre versioner, en vardera för Node.js version 14.x, 16.x och 18.x. Attributet matrix beskrivs på djupet senare i modulen.

jobs I attributet använder stegen åtgärden GitHub Actions/checkout@v3 för att hämta koden från lagringsplatsen till en virtuell dator (VM) och åtgärder/installations-node@v3 för att konfigurera rätt version av Node.js. Du anger att du vill testa tre versioner av Node.js med hjälp av attributet ${{ matrix.node-version }} . Det här attributet refererar till den matris som du definierade tidigare. Attributet cache anger en pakethanterare för cachelagring i standardkatalogen.

Den sista delen av det här steget kör kommandon som Node.js projekt använder. Kommandot npm ci installerar beroenden från package-lock.json filen. npm run build --if-present kör ett byggskript om det finns. npm test kör testramverket. Den här mallen innehåller både bygg- och teststeg i samma jobb.

Mer information om npm finns i npm-dokumentationen:

• npm-installation
• npm-körning
• npm-test

Ett team med utvecklare kan dra nytta av att använda återanvändbara arbetsflöden för att effektivisera och standardisera upprepade automatiseringssteg. Genom att använda återanvändbara arbetsflöden kan du minska redundansen, förbättra underhållsbarheten och säkerställa konsekvens i dina CI/CD-pipelines (kontinuerlig integrering/kontinuerlig distribution).

Undvik duplicering med hjälp av återanvändbara arbetsflöden

När teamen skalas och projekten växer är det vanligt att samma steg upprepas i flera arbetsflödesfiler. De här stegen kan vara att hämta koden, installera beroenden, testning och distribution. Den här typen av duplicering belamrar inte bara kodbasen utan ökar även underhållstiden när kodändringar krävs. Återanvändbara arbetsflöden löser det här problemet genom att du kan definiera automatiseringslogik en gång och sedan anropa logiken från andra arbetsflöden.

Återanvändbara arbetsflöden är särskilda GitHub Actions-arbetsflöden som andra arbetsflöden kan anropa, ungefär som funktioner i programmering. Du skapar dem för att dela upprepad logik som byggsteg, testprocedurer eller distributionsstrategier. När du har skapat ett återanvändbart arbetsflöde kan du referera till det från alla andra arbetsflöden på samma lagringsplats eller till och med i olika lagringsplatser.

Varför ska du använda återanvändbara arbetsflöden?

Det här är fördelarna med att använda återanvändbara arbetsflöden:

• Konsekvens. Teams kan följa samma automatiseringsstandarder i alla projekt.
• Effektivitet. I stället för att kopiera och klistra in steg pekar du bara på ett återanvändbart arbetsflöde.
• Enklare uppdateringar. När en process ändras, till exempel genom att lägga till ett teststeg, uppdaterar du den på en plats. Sedan kommer alla arbetsflöden som drar nytta av arbetsflödet att uppdateras automatiskt.
• Skalbarhet. Återanvändbara arbetsflöden är idealiska för plattforms- eller DevOps-team som hanterar flera tjänster.

Utforska sedan hur du använder återanvändbara arbetsflöden för att förbättra dina projekt.

Implementera återanvändbara arbetsflöden

Så här använder du återanvändbara arbetsflöden:

1. Skapa ett återanvändbart arbetsflöde i lagringsplatsens mapp. Filen innehåller de automatiseringssteg som du vill dela, till exempel vanliga steg som ingår i testning, skapande och distribution.
2. Aktivera uttryckligen att ett arbetsflöde kan återanvändas genom att konfigurera det med workflow_call händelsen.
3. I dina huvudsakliga arbetsflöden (anropararbetsflöden) refererar du till den här återanvändbara filen och anger nödvändiga indata eller hemligheter.

Tänk på följande verkliga scenario för att illustrera fördelarna med återanvändbara arbetsflöden.

Exempel

Anta att din organisation har 10 mikrotjänster. Alla tio mikrotjänster behöver samma steg för att:

• Att köra tester
• Lint-kod
• Distribuera till en specifik miljö

Utan återanvändbara arbetsflöden duplicerar varje lagringsplats samma logik i flera arbetsflödesfiler, vilket leder till upprepade steg och hårdare underhåll.

Om du använder återanvändbara arbetsflöden:

• Du definierar processen en gång i en central fil (till exempel i ci-standard.yml).
• Du anropar den här filen från varje mikrotjänsts eget arbetsflöde och skickar in variabler som miljö eller programnamn.

Om ett nytt säkerhetssteg eller verktyg läggs till, till exempel för att söka efter säkerhetsrisker, lägger du bara till det en gång i det återanvändbara arbetsflödet. Alla 10 mikrotjänster börjar omedelbart använda den uppdaterade processen. Du behöver inte ändra de 10 mikrotjänsterna.

Genom att förstå hur återanvändbara arbetsflöden fungerar och deras fördelar kan du använda metodtips för att maximera deras effektivitet och säkerställa sömlös integrering med dina CI/CD-pipelines.

Metodtips

• Centralisera dina återanvändbara arbetsflöden på en lagringsplats om du planerar att dela dem mellan team.
• Använd grenar eller taggar för att version dina arbetsflöden (till exempel använda @v1), så att du enkelt kan återställa ändringar om det behövs.
• Dokumentera inmatningar och hemligheter tydligt. Återanvändbara arbetsflöden förlitar sig ofta på indata och hemligheter. Teamen behöver veta vilken information som ska användas.
• Om du bara behöver återanvända några få steg kan du kombinera återanvändbara arbetsflöden med sammansatta åtgärder i stället för att skapa ett fullständigt arbetsflöde.

Återanvändbara arbetsflöden är ett kraftfullt sätt att framtvinga konsekvens, minska duplicering och skala DevOps-metoder i alla tekniska team. Oavsett om du hanterar en enda lagringsplats, mikrotjänster eller bibliotek med öppen källkod kan återanvändbara arbetsflöden förenkla automatiseringen, så att din CI/CD blir snabbare, renare och enklare att hantera.

Anpassa arbetsflödesmallar

I början av den här modulen övervägde du ett scenario där du behöver konfigurera CI för ditt team med utvecklare. Mallen Node.js är en bra början, men du vill anpassa den så att den passar teamets behov bättre. Du vill rikta in dig på olika versioner av Node.js och olika operativsystem. Du vill också att bygg- och teststegen ska vara separata jobb.

Här är ett exempel på ett anpassat arbetsflöde:

strategy:
  matrix:
    os: [ubuntu-latest, windows-latest]
    node-version: [16.x, 18.x]

I det här exemplet konfigurerar du en byggmatris för testning över flera operativsystem och språkversioner. Den här matrisen genererar fyra versioner, en för varje operativsystem tillsammans med varje version av Node.js.

Fyra versioner och deras tester producerar en stor mängd loggdata. Det kan vara svårt att sortera igenom allt. I följande exempel flyttar du teststeget till ett dedikerat testjobb. Det här jobbet testar mot flera mål. Genom att separera bygg- och teststegen blir det enklare att arbeta med loggdata.

test:
  runs-on: ${{ matrix.os }}
  strategy:
    matrix:
      os: [ubuntu-latest, windows-latest]
      node-version: [16.x, 18.x]
  steps:
  - uses: actions/checkout@v3
  - name: Use Node.js ${{ matrix.node-version }}
    uses: actions/setup-node@v3
    with:
      node-version: ${{ matrix.node-version }}
  - name: npm install, and test
    run: |
      npm install
      npm test
    env:
      CI: true