CI/CD Pipeline

Den enkleste måten å tenke på en CI/CD-pipelines er som en automatisert monteringslinje i en fabrikk, men for koden din.

I gamle dager ble programvare lansert i store deler, gjerne hvert kvartal. Dette var risikofylte, stressende hendelser hvor alt kunne gå galt (og ofte gjorde det). Målet med CI/CD er å gjøre lanseringer kjedelige, hyppige og trygge ved å automatisere hele prosessen.

Slik fungerer det: hver gang en ingeniør ønsker å legge til eller endre noe, «committer» de koden sin. Denne ene handlingen utløser pipelinen.

En typisk pipeline har flere automatiserte trinn:

1. Build: Systemet tar ingeniørens nye kode og «bygger» den til en kjørbar programvare. Om man oppdager en syntaksfeil, mislykkes byggingen, og pipelinen stopper.

2. Test: Dette er det mest kritiske trinnet. Pipelinen kjører en serie automatiserte tester mot den nybygde koden. Dette kan være «enhetstester» (kontroll av små individuelle komponenter), «integrasjonstester» (kontroll av at forskjellige deler fungerer sammen) og «end-to-end-tester» (simulering av en fullstendig brukeropplevelse).

3. Deploy: Hvis alle testene bestås, distribuerer rørledningen automatisk koden til et staging-miljø (en klone av produksjonsmiljøet) eller direkte til produksjon (dine aktive brukere).

Du kan komme til å høre to CD-begreper:

1. Kontinuerlig levering/ Continuous Delivery: Pipelinen gjør alt *frem til* den endelige distribusjonen. Koden er bygget, testet og klar til bruk, men en person må trykke på den endelige «utgivelsesknappen».

2. Kontinuerlig distribusjon/ Continuous Deploy: Dette er drømmen om full automatisering. Hvis testene bestås, blir koden satt i drift. Ingen menneskelig inngripen er nødvendig. Dette gjør det mulig å gjennomføre dusinvis eller til og med hundrevis av distribusjoner per dag.