CI/CD: Automatisér det, der kan gå galt

En deployment bør ikke være en lille højtid, hvor alle holder vejret. Jo mere manuelt arbejde der ligger i en release, desto større er risikoen for, at noget bliver glemt eller gjort forskelligt fra sidst.

Det er i virkeligheden dét, vi bruger CI/CD til: at gøre de gentagne og risikable trin ens hver gang.

Start ikke med værktøjerne

Det er let at ende i en diskussion om GitHub Actions, Azure DevOps, GitLab eller Jenkins. Vi starter hellere med processen. Hvilke fejl vil vi gerne opdage før produktion? Hvilke trin bliver udført manuelt i dag? Og hvilke af dem er mest sårbare?

For et aktivt forretningssystem giver det typisk mening at automatisere build, test og deployment gradvist. Linting, statisk analyse, unit tests, integrationstests og dependency scanning kan lægges på efter behov. Ikke alle projekter behøver hele kataloget.

Skal produktion så køre automatisk?

Ikke nødvendigvis. Nogle teams har stor glæde af continuous deployment. Andre arbejder i miljøer, hvor en produktionsrelease skal godkendes manuelt eller ligge i et bestemt change window. Det ændrer ikke værdien af automatiseringen. Den manuelle godkendelse kan stadig starte en fuldt reproducerbar deployment.

Rollback er ikke en plan B

Hvis en release går galt, skal teamet vide, hvad næste skridt er. En pipeline uden logging, health checks og en kendt rollback-strategi er kun halvdelen af løsningen.

Også gamle systemer kan få en bedre releaseproces

Et legacy-system behøver ikke blive moderniseret fra bunden, før man kan forbedre deployment. Ofte kan build-processen automatiseres først, derefter tests og til sidst deployment. Hvert trin reducerer risikoen ved at ændre den eksisterende løsning.

Vores princip

Den bedste pipeline er ikke den mest avancerede. Det er den, teamet stoler på og faktisk bruger. Automatisér det, der gentager sig, og især det, der kan gå dyrt galt.