Hoe gebruik ik GitHub Actions om werkstromen voor CI te maken?

Voltooid

Zoals u zich herinnert, is het uw doel om het proces voor het bouwen en publiceren van code te automatiseren, zodat functies telkens worden bijgewerkt wanneer een ontwikkelaar een wijziging aan de codebasis toevoegt.

Als u dit proces wilt implementeren, leert u het volgende:

• Een werkstroom maken op basis van een sjabloon.
• Vermijd duplicatie door herbruikbare werkstromen te gebruiken.
• Test tegen meerdere doelwitten.
• Afzonderlijke build- en testtaken.

Een werkstroom maken op basis van een sjabloon

Als u een werkstroom wilt maken, is het gebruikelijk om te beginnen met het gebruik van een sjabloon. Een sjabloon bevat algemene taken en stappen die vooraf zijn geconfigureerd voor het specifieke type automatisering dat u implementeert. Als u niet bekend bent met werkstromen, taken en stappen, bekijkt u de ontwikkeltaken automatiseren met behulp van de GitHub Actions-module .

Selecteer Acties op de hoofdpagina van uw GitHub-opslagplaats en selecteer vervolgens Nieuwe werkstroom.

Op de pagina Een werkstroom kiezen kunt u kiezen uit een groot aantal typen sjablonen. Een voorbeeld hiervan is de sjabloon Node.js. De Node.js-sjabloon installeert Node.js en alle afhankelijkheden, bouwt de broncode en voert tests uit voor verschillende versies van Node.js. Een ander voorbeeld is de Python-pakketsjabloon , die Python en de bijbehorende afhankelijkheden installeert en vervolgens tests uitvoert, waaronder lint, in meerdere versies van Python.

Als u met de Node.js werkstroomsjabloon wilt beginnen, voert u in het zoekvak Node.jsin.

Selecteer Configureren in de zoekresultaten in het deelvensterNode.js.

Er wordt een node.js.yml bestand voor uw project gemaakt op basis van de sjabloon:

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

Zoals u in het on kenmerk ziet, wordt deze voorbeeldwerkstroom uitgevoerd als reactie op een push naar de opslagplaats of wanneer een pull-aanvraag wordt gemaakt op basis van de hoofdbranch.

Met deze werkstroom wordt één taak uitgevoerd, aangegeven door het job kenmerk.

Het kenmerk runs-on geeft aan dat de werkstroom voor het besturingssysteem wordt uitgevoerd op ubuntu-latest. Het node-version kenmerk geeft aan dat er drie builds zijn, één voor Node.js versie 14.x, 16.x en 18.x. Het matrix kenmerk wordt verderop in de module uitgebreid beschreven.

In het jobs kenmerk gebruiken de stappen de Acties van GitHub Actions /checkout@v3 actie om de code op te halen uit uw opslagplaats naar een virtuele machine (VM) en acties/setup-node@v3 om de juiste versie van Node.jsin te stellen. U geeft op dat u drie versies van Node.js wilt testen met behulp van het ${{ matrix.node-version }} kenmerk. Dit kenmerk verwijst naar de matrix die u eerder hebt gedefinieerd. Het kenmerk cache geeft een pakketbeheerder op voor caching in de standaardmap.

In het laatste deel van deze stap worden opdrachten uitgevoerd die Node.js projecten gebruiken. Met npm ci de opdracht worden afhankelijkheden uit het package-lock.json bestand geïnstalleerd. npm run build --if-present voert een buildscript uit als dit bestaat. npm test voert het testframework uit. Deze sjabloon bevat zowel build- als teststappen in dezelfde taak.

Raadpleeg de npm-documentatie voor meer informatie over npm:

• npm installeren
• npm-uitvoering
• npm-test

Een team van ontwikkelaars kan profiteren van het gebruik van herbruikbare werkstromen om herhaalde automatiseringsstappen te stroomlijnen en te standaardiseren. Door herbruikbare werkstromen te gebruiken, kunt u redundantie verminderen, de onderhoudbaarheid verbeteren en consistentie garanderen in uw CI/CD-pijplijnen (continue integratie/continue implementatie).

Duplicatie voorkomen door herbruikbare werkstromen te gebruiken

Naarmate teams schalen en projecten groeien, is het gebruikelijk om dezelfde stappen te zien die in meerdere werkstroombestanden worden herhaald. Deze stappen kunnen bestaan uit het uitchecken van code, afhankelijkheidsinstallatie, testen en implementatie. Dit soort duplicatie vervuilt niet alleen uw codebasis, maar verhoogt ook de tijd voor onderhoud wanneer er wijzigingen in de code nodig zijn. Herbruikbare werkstromen lossen dit probleem op door u in staat te stellen automatiseringslogica eenmaal te definiëren en vervolgens de logica van andere werkstromen aan te roepen.

Herbruikbare werkstromen zijn speciale GitHub Actions-werkstromen die andere werkstromen kunnen aanroepen, vergelijkbaar met functies in programmeren. U maakt deze om herhaalde logica te delen, zoals buildstappen, testprocedures of implementatiestrategieën. Nadat u een herbruikbare werkstroom hebt gemaakt, kunt u ernaar verwijzen vanuit elke andere werkstroom in dezelfde opslagplaats of zelfs in verschillende opslagplaatsen.

Waarom herbruikbare werkstromen gebruiken?

Dit zijn de voordelen van het gebruik van herbruikbare werkstromen:

• Consistentie. Teams kunnen dezelfde automatiseringsstandaarden voor alle projecten volgen.
• Efficiëntie. In plaats van stappen te kopiëren en plakken, wijst u alleen naar een herbruikbare werkstroom.
• Eenvoudigere updates. Wanneer een proces verandert, bijvoorbeeld door een teststap toe te voegen, werkt u deze bij op één locatie. Vervolgens profiteren alle werkstromen die gebruikmaken van de workflow automatisch van de voordelen.
• Schaalbaarheid. Herbruikbare werkstromen zijn ideaal voor platform- of DevOps-teams die meerdere services beheren.

Bekijk vervolgens hoe u herbruikbare werkstromen kunt gebruiken om uw projecten te verbeteren.

Herbruikbare werkstromen implementeren

Herbruikbare werkstromen gebruiken:

1. Maak een herbruikbare werkstroom in uw opslagplaatsmap. Het bestand bevat de automatiseringsstappen die u wilt delen, zoals veelvoorkomende stappen bij het testen, bouwen en implementeren.
2. U kunt een workflow expliciet herbruikbaar maken door deze te configureren met de workflow_call gebeurtenis.
3. Raadpleeg dit herbruikbare bestand in uw hoofdwerkstromen (werkstromen voor bellers) en geef de vereiste invoer of geheimen op.

Bekijk het volgende praktijkscenario om de voordelen van herbruikbare werkstromen te illustreren.

Voorbeeld

Stel dat uw organisatie 10 microservices heeft. Alle 10 microservices hebben dezelfde stappen nodig om:

• Tests uitvoeren
• Lintcode
• Implementeren in een specifieke omgeving

Zonder herbruikbare werkstromen wordt in elke opslagplaats dezelfde logica gedupliceerd in meerdere werkstroombestanden, wat leidt tot herhaalde stappen en moeilijker onderhoud.

Als u herbruikbare werkstromen gebruikt:

• U definieert het proces eenmaal in een centraal bestand (bijvoorbeeld in ci-standard.yml).
• U roept dit bestand aan vanuit de eigen werkstroom van elke microservice, waarbij u variabelen zoals omgeving of de naam van de toepassing doorgeeft.

Als er een nieuwe beveiligingsstap of een nieuw hulpprogramma wordt toegevoegd, bijvoorbeeld om te scannen op beveiligingsproblemen, voegt u deze slechts één keer toe in de herbruikbare werkstroom. Alle 10 microservices beginnen onmiddellijk met het bijgewerkte proces. U hoeft de 10 microservices niet te wijzigen.

Door te begrijpen hoe herbruikbare werkstromen en hun voordelen werken, kunt u best practices gebruiken om hun effectiviteit te maximaliseren en naadloze integratie met uw CI/CD-pijplijnen te garanderen.

Beste praktijken

• Centraliseer uw herbruikbare werkstromen in één opslagplaats als u ze wilt delen tussen teams.
• Gebruik vertakkingen of tags om uw werkstromen te versien (bijvoorbeeld gebruiken @v1), zodat u wijzigingen eenvoudig kunt terugdraaien als dat nodig is.
• Documenteer ingevoerde gegevens en geheimen duidelijk. Herbruikbare werkstromen zijn vaak afhankelijk van invoer en geheimen. Teams moeten weten welke gegevens moeten worden gebruikt.
• Als u slechts een paar stappen opnieuw moet gebruiken, combineert u herbruikbare werkstromen met samengestelde acties in plaats van een volledige werkstroom te maken.

Herbruikbare werkstromen zijn een krachtige manier om consistentie af te dwingen, duplicatie te verminderen en DevOps-procedures in elk technisch team te schalen. Of u nu één opslagplaats, microservices of opensource-bibliotheken beheert, herbruikbare werkstromen kunnen automatisering vereenvoudigen, zodat uw CI/CD sneller, schoner en eenvoudiger te beheren is.

Werkstroomsjablonen aanpassen

Aan het begin van deze module hebt u een scenario overwogen waarin u CI moet instellen voor uw team van ontwikkelaars. De Node.js-sjabloon is een goed begin, maar u wilt deze aanpassen aan de vereisten van uw team. U wilt zich richten op verschillende versies van Node.js en verschillende besturingssystemen. U wilt ook dat de build- en teststappen afzonderlijke taken zijn.

Hier volgt een voorbeeld van een aangepaste werkstroom:

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

In dit voorbeeld configureert u een buildmatrix voor het testen van meerdere besturingssystemen en taalversies. Deze matrix produceert vier builds, één voor elk besturingssysteem dat is gekoppeld aan elke versie van Node.js.

Vier builds en hun tests produceren een grote hoeveelheid logboekgegevens. Het kan lastig zijn om alles te sorteren. In het volgende voorbeeld verplaatst u de teststap naar een toegewezen testtaak. Deze taak test tegen meerdere doelen. Door de build- en teststappen te scheiden, is het eenvoudiger om met de logboekgegevens te werken.

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