Themagids

CI/CD-automatisering: hoe een wijziging van commit naar productie komt

CI/CD-automatisering maakt van de handmatige weg van commit naar release een pipeline: een vaste reeks fasen die elke wijziging op dezelfde manier bouwt, test, deployt en controleert. Deze gids ontleedt die pipeline fase voor fase.

Wat zijn de fasen van een CI/CD-pipeline?

Martin Fowler beschrijft een deploymentpipeline als een build die is opgedeeld in fasen. Elke fase geeft meer zekerheid, meestal ten koste van extra tijd. Hoe uw tools de fasen ook noemen, bij elke fase staat wat een groen resultaat daar garandeert.

Continuous integration

Bij elke push naar mainline, binnen minuten

  1. 1

    Commit

    De wijziging is klein, staat op mainline, en alles wat de build nodig heeft, staat in versiebeheer.

  2. 2

    Build

    Eén commando maakt van de commit één geversioneerd artifact. Geen latere fase bouwt het opnieuw.

  3. 3

    Snelle tests

    Unittests en statische controles slagen binnen enkele minuten. Een fout herstellen gaat vóór ander werk.

Continuous delivery

De rest van de pipeline, tot een build die klaar is voor release

  1. 4

    Acceptatie

    Tragere suites slagen in een omgeving die op productie lijkt. Ze draaien parallel, op hetzelfde artifact.

  2. 5

    Staging

    Het deploy-script van productie heeft hier net gewerkt, dus ook de deployment zelf is getest.

  3. 6

    Goedkeuring

    De goedkeuring die uw beleid vereist, gebeurt binnen de run en wordt vastgelegd. Bij continuous deployment gaat die automatisch.

  4. 7

    Productie

    Hetzelfde artifact staat live, en controles na de deploy bevestigen dat het goed draait.

De weg terug

Falen die controles, dan deployt de pipeline het laatste goede artifact opnieuw, zonder een nieuwe build. De fix of revert begint daarna weer bij commit.

  • Elke fase geeft meer zekerheid en duurt langer
  • Een handmatige goedkeuring
  • De weg terug
Illustratie: een deliverypipeline van commit tot een gecontroleerde deploy in productie, wat een groen resultaat in elke fase garandeert, en de weg terug.

Wat is het verschil tussen continuous integration, delivery en deployment?

De drie termen beschrijven hoe ver de automatisering reikt, en elke term bouwt voort op de vorige. DORA merkt op dat continuous delivery vaak wordt verward met continuous deployment, maar het zijn twee aparte werkwijzen.

Continuous integration, continuous delivery en continuous deployment vergeleken
WerkwijzeWat het inhoudtHoe ver de automatisering reiktWie beslist over de release
Continuous integration Iedereen merget minstens dagelijks naar mainline, en een geautomatiseerde build met tests controleert elke merge (Fowler). Een geteste build op mainline. CI op langlevende featurebranches is volgens Fowler geen continuous integration. Valt erbuiten: CI stopt vóór de deployment.
Continuous delivery Software die u op elk moment naar productie kunt releasen (Fowler). DORA omschrijft het als het vermogen om wijzigingen op verzoek snel, veilig en duurzaam te releasen. Alles tot aan productie. Releasen is één druk op de knop. Een persoon of een beleidsregel, bij de goedkeuring.
Continuous deployment Elke wijziging die door de geautomatiseerde fasen komt, gaat vanzelf naar productie (Fowler). Helemaal. Geautomatiseerde controles vervangen de goedkeuring. De pipeline. Daarvoor is eerst continuous delivery nodig.

Waar moet een team naar streven?

Voor de meeste teams is dat continuous delivery: de business kiest het moment, en elke dag kan een releasedag zijn. Continuous deployment is een keuze daarbovenop. Hoe dan ook waarschuwt DORA dat vaker deployen zonder de processen en de architectuur te verbeteren, waarschijnlijk leidt tot hogere faalpercentages en opgebrande teams.

Hoe ziet een CI/CD-pipeline eruit als code?

In Jenkins is de pipeline een Jenkinsfile in de repository van het project. De documentatie van Jenkins noemt wat dat oplevert: een pipeline voor elke branch en pull request, codereview op de pipeline, een audittrail en één bron van waarheid.

Hier ziet u de pipeline van hierboven, ingekort. De letters verwijzen naar de toelichting.

Jenkinsfile

pipeline {
  agent none
  options { disableConcurrentBuilds() }
  stages {
    stage('Before production') {
      agent any
      stages {
        stage('Build') {
          steps { sh './build.sh --publish' }
        }
        stage('Fast tests') {
          options { timeout(time: 10, unit: 'MINUTES') }
          steps { sh './test.sh unit' }
        }
        stage('Acceptance') {
          parallel {
            stage('API') { steps { sh './test.sh api' } }
            stage('UI')  { steps { sh './test.sh ui' } }
          }
        }
        stage('Staging') {
          when { branch 'main' }
          steps {
            sh './deploy.sh staging'
            sh './smoke-test.sh staging'
          }
        }
      }
    }
    stage('Production') {
      agent any
      when {
        beforeInput true
        branch 'main'
      }
      input {
        message 'Deploy to production?'
        submitter 'release-approvers'
      }
      steps {
        sh './deploy.sh production'
        sh './smoke-test.sh production'
      }
      post {
        failure { sh './deploy.sh production --previous' }
      }
    }
  }
}
Illustratie: een ingekorte, declaratieve Jenkinsfile voor een multibranch-job, volgens de syntaxisreferentie van Jenkins Pipeline. De scripts staan voor uw eigen commando's.

  1. Zonder agent op het hoogste niveau bezet een release die op goedkeuring wacht geen executor. Runs van dezelfde branch overlappen elkaar nooit.

  2. Bouw één keer en publiceer het artifact. Latere fasen deployen het en bouwen nooit opnieuw.

  3. De commitfase krijgt een budget van tien minuten. Een tragere run wordt gestopt, zodat trage tests niet ongemerkt blijven.

  4. De suites draaien naast elkaar: de fase duurt zo lang als de langste, niet als de optelsom.

  5. Staging draait het deploy-script van productie en daarna de smoketests.

  6. beforeInput controleert de branch voordat er om goedkeuring wordt gevraagd, zodat featurebranches nooit wachten. Alleen de genoemde groep kan goedkeuren. Zonder het goedkeuringsblok is dit continuous deployment.

  7. De weg terug: falen de deploy naar productie of de smoketests, dan deployt deze fase de vorige versie opnieuw.

Wat automatiseert u als eerste?

Werk in de volgorde waarin de fasen van elkaar afhangen, zodat elke stap de volgende goedkoper maakt.

  1. Maak van de build één commando

    Heeft een build een bepaalde persoon of machine nodig, dan valt niets daarna te automatiseren. Zet alles wat de build nodig heeft in versiebeheer, ook de pipeline zelf.

    Fasen: CommitBuild

  2. Draai de snelle tests bij elke push

    Start de build en de tests bij elke push naar mainline. DORA legt de bovengrens voor die feedback bij ongeveer tien minuten.

    Fasen: Snelle tests

  3. Schrijf de deploy op en script hem daarna

    De eerste stap die DORA noemt voor de automatisering van deployments, is het bestaande proces documenteren. Script het daarna één keer en gebruik dat script voor elke omgeving, ook voor productie.

    Fasen: StagingProductie

  4. Controleer elke deploy en automatiseer de weg terug

    Controles na de deploy en een rollback die in staging is geoefend, maken van een slechte release een korte.

    Fasen: ProductieWeg terug

  5. Verplaats goedkeuringen naar de pipeline

    DORA stelde vast dat een zware externe goedkeuring van wijzigingen de softwarelevering vertraagt, zonder bewijs dat het faalpercentage van wijzigingen erdoor daalt. Houd de goedkeuring die uw beleid vereist, maar dan binnen de run.

    Fasen: Goedkeuring

  6. Maak het daarna sneller

    Parallelle suites, testomgevingen die op productie lijken, progressive delivery en, waar de business dat wil, continuous deployment.

    Fasen: AcceptatieAlle fasen

Twijfelt u tussen twee kandidaten? Tel per kandidaat de handmatige stappen en de wachttijd, zoals DORA voorstelt, en begin met degene die het vaakst draait.

Hoe ziet CI-automatisering eruit in een echte opdracht?

Bij ASML draaide continuous integration voor het domein Stage Position Measurement in eigen testomgevingen, en handmatige integratiestappen remden het af. Engineers voerden herhaalbare stappen met de hand uit en hadden geen centrale plek om te beoordelen of een release klaar was.

Het werk raakte drie delen van de pipeline, zoals het overzicht laat zien. In de ASML-case leest u de details.

Wat ook buiten ASML geldt: als tests schaarse hardware nodig hebben, bepalen de fasen na de build het tempo. Daar lonen gedeelde flows, meer testcapaciteit en één overzicht van de releasegereedheid.

300+engineeringuren per jaar bespaard door handmatige integratiestappen te schrappen

Waar het werk bij ASML in de pipeline hierboven zat

Fase 1 tot en met 3Van commit tot snelle tests
Self-service CI-pipelines in Jenkins, geschreven in Groovy, met automatiseringsscripts in Python en Bash, op Linux met Git en ClearCase.
Fase 4Acceptatie
CI-flows gestandaardiseerd voor meerdere teams, in eigen testomgevingen. Het verhuizen van geselecteerde tests van productiemachines naar Google Cloud Platform is gestart, voor meer doorvoer en kortere feedbackcycli.
Fase 6Goedkeuring
Eén rapportageoverzicht in Python en SQL van de testresultaten van productiemachines, zodat er voor het besluit over de releasegereedheid één plek is om te kijken.

Hoe meet u een CI/CD-pipeline?

Begin met de metrics van DORA voor de leverprestaties van software. DORA gebruikt er nu vijf, in twee groepen. Meet ze per applicatie of service, lees ze in samenhang en gebruik ze om een service in de loop van de tijd te verbeteren, niet om teams te rangschikken.

Doorvoer

Doorlooptijd van wijzigingen
De tijd van de commit van een wijziging in versiebeheer tot die wijziging in productie draait.
Af te lezen uit de tijdstempels van commit en deploy in de historie van de pipeline.
Deploymentfrequentie
Het aantal deployments in een periode, of de tijd ertussen.
Af te lezen uit de runs die productie bereiken.
Hersteltijd na een mislukte deployment
De tijd om te herstellen van een deployment die mislukt en direct ingrijpen vereist.
Te meten vanaf de mislukte deploy tot het einde van de weg terug.

Instabiliteit

Faalpercentage van wijzigingen
Het aandeel deployments dat daarna direct ingrijpen vereist.
Af te lezen uit productieruns die gevolgd worden door een rollback of een hotfix.
Herwerkpercentage van deployments
Het aandeel deployments dat ongepland is en voortkomt uit een incident in productie.
Af te lezen uit deploys die aan een incidentticket gekoppeld zijn.

Een laag dieper

De capability-pagina's van DORA raden ook aan om de pipeline zelf te meten:

  • Het aandeel commits dat zonder handmatige stap een build en tests start
  • De tijd van een kapotte build tot de fix of revert
  • De handmatige stappen in een deployment, en de wachttijd tussen fasen
  • De tijd dat wijzigingen op goedkeuring wachten

Twee waarschuwingen van DORA: zodra een metric een doel wordt, gaan mensen hem manipuleren, en één metric op zichzelf misleidt. Ons artikel over de vier DORA-metrics gaat er dieper op in.

Wat gaat er mis in CI/CD-pipelines, en hoe lost u het op?

Problemen in een pipeline worden meestal ver van hun oorzaak zichtbaar. Begin bij wat het team merkt.

Veelvoorkomende symptomen in pipelines, hun waarschijnlijke oorzaken en oplossingen
Wat het team merktWaarschijnlijke oorzaakOplossing
Builds duren bijna een uur, dus mensen bundelen wijzigingenAlle tests draaien in één seriële faseSplits een commitfase af die binnen tien minuten antwoord geeft, en draai tragere suites daarna parallel.
Opnieuw draaien tot alles groen is, is normaalFlaky tests worden getolereerdZet ze in quarantaine en los ze op. De norm van DORA: een falende test wijst altijd op een echte fout.
Groen in staging, kapot in productieAndere artifacts of deploy-stappen per omgevingBouw één keer. Promoot dat artifact overal met hetzelfde deploy-proces.
Mainline blijft dagenlang roodNiemand is eigenaar van een kapotte buildFix of revert meteen. Fowler citeert Kent Beck: niemand heeft een taak met een hogere prioriteit dan het repareren van de build.
Elke merge is een klein projectLanglevende featurebranchesMerge minstens dagelijks naar mainline, met hooguit drie actieve branches, zoals trunk-based development vraagt.
Een rollback begint met een vergaderingDe weg terug is nooit geautomatiseerdScript het opnieuw deployen van het laatste goede artifact en oefen dat in staging.
Slechts één persoon kan de pipeline wijzigenJobinstellingen staan in een UI, niet in de repositoryLeg de pipeline vast als code en train het team erin. Bij Nike zijn de andere platform engineers getraind op de tooling, zodat de kennis niet bij één persoon bleef.

Verder lezen

Uw eigen pipeline

Waar verliest uw release tijd?

De gratis Release Check laat in minder dan 5 minuten zien waar de tijd van uw laatste release naartoe ging en wat dat per jaar kost, zonder gesprek.

Doe de gratis Release Check