CI/CD-pipeline — fra commit til produktion

CI/CD-pipeline — fra commit til produktion

The interactive FlowJam canvas for this explanation — every lane, row and arrow above is a real QueryChart diagram you can open and edit.

How to read this visual

• Læs de fem kolonner fra venstre mod højre: Commit, Byg og test, Pak, Deploy, Overvåg.
• Følg ændringen på tværs af banerne: den forlader udvikleren, behandles af CI-serveren, ligger i registryet og kører på deployment-målet.
• De to beslutninger er gates — et »Nej« ved en af dem sender ændringen til et eksplicit fejlslutpunkt i stedet for videre frem.

Build og test

»Udvikleren committer kode« sætter forløbet i gang, og »CI-serveren bygger applikationen« og »Unit- og integrationstests kører« er continuous integrations opgave: hvert commit bliver bygget og testet for sig. »Bestod alle tjek?« er den gate, der giver CI sit navn — et fejlende commit afvises ved »Buildet fejlede — ret og commit igen«, før det kan forurene strømmen af artefakter.

Pakning og deployment

»Pak artefaktet, og push det til registryet« producerer det uforanderlige, versionerede build — præcis det, der kommer til at køre. »Deploy til staging, og kør smoke tests« beviser det i et miljø, der ligner produktion, og derefter sender »Deploy til produktion« det af sted. Registry-banen er overleveringen: artefaktet bygges én gang og bruges af alle senere trin, og det er det, der gør den deployede version identisk med den testede.

Overvågningsgaten

»Sund efter deploy?« er den sidste beslutning: metrikker, logs og alarmering efter releasen afgør, om det bliver »Releasen er live og overvåget« eller »Rul tilbage til den sidste gode version«. Rollbacket er tegnet som et reelt trin, der fører tilbage til den sunde sluttilstand, for det er det automatiske rollback, der gør hurtig deployment sikker.

Key relationships and takeaways

• CI er gaten, før noget som helst sendes af sted: byg og test hvert commit, og afvis fejlene ved kilden.
• Artefaktet i registryet bygges én gang og køres alle steder — reproducerbar deployment afhænger af det.
• Staging beviser artefaktet i et produktionslignende miljø, før produktion ser det.
• Sundheden efter deploy er den reelle gate — det er overvågningen, ikke deploy-scriptet, der afgør, om en release bliver.
• En pipeline uden et rollback er ikke sikker at automatisere; lærredet tegner rollback som en fuldgyldig vej.

When to use this visual

• At lære et team forskellen på continuous integration og continuous delivery, før de bygger en pipeline.
• At designe en pipeline: de to gates fortæller, hvor automatikken skal stoppe, og hvor dømmekraften (eller et rollback) skal begynde.
• At gennemgå en eksisterende pipeline — en manglende sundhedsgate er en release, der kører uden en beslutning.

Sådan fungerer det

1. Kortlæg jeres faktiske pipelinetrin

   Erstat de generiske trin med dem, jeres CI kører — lint, container-build, migrering, canary — og behold en gate, før noget sendes af sted.

2. Navngiv jeres tjek

   Annotér testboksen med de suiter og sikkerhedsscanninger, I faktisk kører, og med hvad gaten »Bestod alle tjek?« kræver ud over unit-tests.

3. Tilføj canary-grenen

   Indsæt et canary-trin mellem staging og produktion — send en lille del af trafikken til den nye version, og hold øje med sundhedsgaten før fuld udrulning.

4. Beskriv jeres rollback

   Notér på rollback-boksen, hvad det faktisk gør i jeres system — deployer det forrige image igen, gendanner en databasebackup — og hvem eller hvad der udløser det.

Ofte stillede spørgsmål

Hvad er forskellen på CI og CD?

Continuous integration (CI) er den praksis at bygge og teste hvert eneste commit automatisk, så problemerne dukker op i det øjeblik, de bliver introduceret, i stedet for ved release. Continuous delivery (CD) tager resultatet af CI og automatiserer dets vej videre til deployment — pakning, staging, release — med gates, der afgør, hvornår det er sikkert. CI er den første gate i pipelinen, CD er alt det, der kommer efter.

Hvorfor er gates vigtige i en CI/CD-pipeline?

Fordi automatikken fjerner de menneskelige kontrolpunkter, der før fangede problemerne. Pipelinens gates erstatter dem med beslutninger: testgaten stopper et fejlende build, før det sendes af sted, og sundhedsgaten stopper en dårlig release, efter den er sendt af sted. Derfor tegner diagrammet dem begge som beslutningsfigurer — en pipeline er kun så troværdig som sine gates.

Hvad er et rollback, og hvorfor har pipelinen brug for et?

Et rollback er at føre systemet tilbage til den sidste kendte gode version, når en release fejler efter deployment. Pipelines har brug for det, fordi sundhedstjek er ufuldkomne, og fordi produktion kan opføre sig på måder, staging aldrig viste. Et automatisk rollback er det, der gør det muligt for teams at deploye ofte — prisen for en dårlig release bliver en tilbagerulning, ikke en driftshændelse.

Hvordan passer artefakt-registryet ind?

Registryet er der, hvor pipelinens byggede artefakt ligger med en version. Alle senere trin — staging, produktion, rollback — deployer præcis det artefakt fra registryet, aldrig et nyt build. Det er det, der gør den deployede kode identisk med den testede, og det er også det, der gør rollback sikkert: den sidste gode version ligger stadig i registryet.

Redigér dette diagram i QueryChart (FlowJam)

Åbn præcis dette CI/CD-lærred som dit eget diagram, omdøb trinnene til jeres egen pipeline, og tilføj jeres egne gates.

Redigér dette diagram i QueryChart (FlowJam)