Continuous Integration forklaret

Continuous Integration bygger på nogle få grundlæggende idéer:

• Brug versionsstyring: Al kode ligger i et delt repository (f.eks. Git).
• Hyppige commits: Udviklere committer ofte små ændringer, normalt flere gange om dagen.
• Automatiseret build: Hver commit udløser en automatiseret proces, der kompilerer koden.
• Automatiserede test: Efter buildet køres en samling automatiserede test for at verificere funktionaliteten.
• Øjeblikkelig feedback: Udviklerne får hurtige beskeder, hvis buildet eller testene mislykkes.

Den del af CI, der handler om 'automatiserede test', er afgørende. Uden gode test opdager CI ikke problemer effektivt.

Disse test omfatter typisk:

• Enhedstest: Tester individuelle komponenter eller funktioner.
• Integrationstest: Kontrollerer, at forskellige dele af applikationen fungerer korrekt sammen.
• End-to-end-test: Simulerer brugerscenarier for at teste hele applikationsflowet.

Hurtige og pålidelige test er afgørende for hurtige feedbackcyklusser i CI.

Sådan forløber en typisk CI-cyklus:

1. En udvikler skriver kode og committer den til versionsstyringssystemet.
2. Udvikleren pusher sine ændringer til det delte repository.
3. En CI-server (f.eks. Jenkins, GitLab CI) registrerer den nye commit.
4. CI-serveren henter den nyeste kode, kompilerer den og kører alle automatiserede test.
5. Hvis alt består, markeres buildet som 'grønt'. Ellers er det 'rødt'.
6. Udviklerne får besked om buildets status, så de hurtigt kan rette problemer efter behov.

En CI-server er motoren i Continuous Integration. Det er et dedikeret værktøj, der:

• Overvåger dit koderepository for nye ændringer.
• Udløser en buildproces automatisk, når der registreres ændringer.
• Kører foruddefinerede scripts for at kompilere kode, udføre test og foretage andre kontroller.
• Indsamler testresultater og leverer rapporter.
• Giver udviklerne besked om buildets status (succes eller fejl).

Populære CI-servere omfatter Jenkins, GitLab CI, GitHub Actions og Travis CI.

En CI-server udfører en række kommandoer, der er defineret i et buildscript. Her er et simpelt Java-program, der simulerer disse trin. I en rigtig CI-pipeline ville det være faktiske kommandoer som git pull, mvn clean install og mvn test.

Implementering af Continuous Integration giver udviklingsteams betydelige fordele:

• Tidlig fejlfinding: Problemer opdages og løses næsten med det samme, efter at de er blevet introduceret.
• Hurtigere feedbacksløjfer: Udviklere får hurtigt at vide, om deres ændringer har ødelagt noget.
• Reducerede integrationsrisici: Hyppige, små sammenfletninger er meget nemmere at håndtere end store, sjældne sammenfletninger.
• Bedre kodekvalitet: Konsekvent testning og øjeblikkelig feedback fremmer bedre programmeringspraksis.
• Hurtigere udgivelsescyklusser: En stabil kodebase, der løbende testes, er altid klar til implementering.

Følg disse bedste praksisser for at få mest muligt ud af Continuous Integration:

• Commit småt og ofte: Foretag hyppige, små ændringer i kodebasen.
• Hold buildet grønt: Håndter fejl i buildet med det samme, og lad være med at committe, hvis buildet er rødt.
• Skriv gode tests: Sørg for, at dine automatiserede tests er omfattende, hurtige og pålidelige.
• Hurtige builds: Optimer din buildproces, så den afsluttes hurtigt.
• Ødelæg ikke buildet: Commit aldrig kode, der får buildet til at mislykkes. Hvis det sker, skal du rette det hurtigst muligt.

Du har nu lært om Continuous Integration!

CI er en udviklingspraksis, hvor udviklere ofte sammenfletter deres kode i et centralt lager, og hver sammenfletning udløser en automatiseret build- og testproces. Det hjælper teams med at opdage fejl tidligt, få hurtig feedback og vedligeholde en kodebase af høj kvalitet, der er klar til implementering.

Det er en grundlæggende praksis i enhver succesfuld DevOps-pipeline, som fører til mere stabil software og mere tilfredse udviklingsteams. Derefter undersøger vi Continuous Delivery og Deployment!