CI/CD-pipeline · Mindmaps
CI/CD-pipeline. Et redigerbart mindmap med farvede grene, underemner og forbindelser. Buede linjer viser sammenhænge; pile bruges, når retningen har betydning.
CI/CD automatiserer vejen fra et commit til produktion: continuous integration bygger og tester hver eneste ændring, og continuous delivery pakker den og deployer den gennem gates, der afgør, om releasen er sund nok til at blive.
CI/CD-pipeline · Mindmaps
The interactive MindMap canvas for this explanation — every lane, row and arrow above is a real QueryChart diagram you can open and edit.
Sådan læser du mindmappet
- Begynd ved emnet i midten, og følg en farvet gren til de tilhørende idéer.
- Buede linjer viser sammenhænge; pile bruges, når retningen har betydning.
Commit & build
Denne gren samler “Developer commits code”, “CI server builds the application”.
Verify
Denne gren samler “Unit and integration tests run”, “The gate is what makes it CI: a commit that fails a test or a security scan never reaches the registry, let alone production.”, “Build failed — fix and recommit”.
Package
Denne gren samler “Package the artifact and push to the registry”.
Release
Denne gren samler “Deploy to staging and run smoke tests”, “Deploy to production”.
Observe & recover
Denne gren samler “Deployment is not the end of the pipeline: error rates, latency and availability metrics decide whether the release stays.”, “Release is live and monitored”, “Roll back to the last good version”.
Forbindelser på tværs
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.
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
Tilpas emnet i midten
Giv emnet et navn, der passer til dit projekt eller din undervisning.
Udbyg grenene
Rediger idéerne, og tilføj eksempler eller noter.
Forbind beslægtede idéer
Tegn forbindelser på tværs af grene; brug kun pile, når retningen betyder noget.
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.
Rediger dette mindmap i QueryChart
Åbn mindmappet på et redigerbart lærred. Flyt idéer, tilføj grene, og tegn forbindelser.