Continue integratie vs. levering vs. implementatie
Ontdek de verschillen tussen deze continue praktijken
Sten Pittet
Mede-auteur
CI en CD zijn twee afkortingen die vaak worden gebruikt in moderne ontwikkelingspraktijken en DevOps. CI staat voor continue integratie, een fundamentele best practice van DevOps waarbij ontwikkelaars regelmatig codewijzigingen samenvoegen in een centrale repository waar geautomatiseerde builds en tests worden uitgevoerd. Maar CD kan ofwel continue levering of continue implementatie betekenen.
Wat zijn de verschillen tussen continue integratie, continue levering en continue implementatie (CI/CD)?
Continue integratie
Ontwikkelaars die continue integratie toepassen, voegen hun wijzigingen zo vaak mogelijk weer samen met de main-branch. De wijzigingen van de ontwikkelaar worden gevalideerd door een build te maken en geautomatiseerde tests uit te voeren op basis van de build. Op deze manier voorkom je integratieproblemen die kunnen optreden als je op de dag van de release wacht om wijzigingen samen te voegen in de releasebranch.
Contnue integratie legt een grote nadruk op automatiseringen testen om te controleren of de applicatie niet kapot gaat wanneer nieuwe commits worden geïntegreerd in de main-branch.
Continue levering
Continue levering is een uitbreiding van continue integratie, aangezien alle codewijzigingen automatisch worden geïmplementeerd in een test- en/of productieomgeving na de buildfase.
Dit betekent dat je naast geautomatiseerde tests ook een automatisch releaseproces hebt en dat je je toepassing op elk gewenst moment kunt implementeren door op een knop te klikken.
In theorie kun je met continue levering besluiten om dagelijks, wekelijks, tweewekelijks of wat het beste past bij je zakelijke behoeften releases uit te brengen. Als je echter echt wilt profiteren van de voordelen van continue levering, moet je zo vroeg mogelijk implementeren naar de productie om er zeker van te zijn dat je releases in kleine batches waarvoor eenvoudig een oplossing voor gevonden kan worden bij problemen.
Oplossing bekijken
Software bouwen en gebruiken met Open DevOps
Gerelateerd materiaal
Wat is de DevOps-pipeline?
Continue implementatie
Continue implementatie gaat nog een stap verder dan continue levering. Met deze praktijk wordt elke wijziging die alle fasen van je productiepipeline doorloopt, gereleased aan je klanten. Er is geen handmatife tussenkomst en alleen een mislukte test kan voorkomen dat er een nieuwe verandering in de productie wordt doorgevoerd.
Continue implementatie is een uitstekende manier om de feedbackloop met je klanten te versnellen en de druk op het team te verminderen, aangezien er geen 'releasedag' meer is. Ontwikkelaars kunnen zich concentreren op software ontwikkelen, en ze zien hun werk enkele minuten nadat ze klaar zijn met werken live gaan.
Hoe de praktijken zich tot elkaar verhouden
Simpel gezegd, continue integratie maakt deel uit van zowel continue levering als continue implementatie. En continue implementatie is hetzelfde als continue levering, met het verschil dat releases automatisch plaatsvinden.
Welke voordelen biedt elke praktijk?
What are the benefits of each practice?
We hebben het verschil uitgelegd tussen continue integratie, continue levering en continue implementaties, maar we hebben nog niet gekeken naar de redenen waarom je ze zou gebruiken. Er zitten natuurlijk kosten verbonden aan elke praktijk, maar deze worden grotendeels overtroffen door hun voordelen.
Continue integratie
Wat je nodig hebt (kosten)
- Je team moet geautomatiseerde tests schrijven voor elke nieuwe functie, verbetering of bugfix.
- Je hebt een server voor continue integratie nodig die de hoofdrepository kan controleren en de tests automatisch kan uitvoeren voor elke nieuwe gepushte commit.
- Ontwikkelaars moeten hun wijzigingen zo vaak mogelijk samenvoegen, minstens één keer per dag.
Wat je krijgt (baten)
- Er worden minder bugs aan de productie geleverd omdat regressies in een vroeg stadium worden vastgesteld door de geautomatiseerde tests.
- De release samenstellen is eenvoudig omdat alle integratieproblemen eerder al zijn opgelost.
- Er hoeft minder van context te worden gewisseld. Ontwikkelaars worden gewaarschuwd zodra ze de build breken en ze kunnen aan een oplossing werken voordat ze aan een andere taak beginnen.
- De testkosten worden drastisch verlaagd: je CI-server kan binnen enkele seconden honderden tests uitvoeren.
- Je QA-team besteedt minder tijd aan testen en kan zich concentreren op aanzienlijke verbeteringen in de kwaliteitscultuur.
Continue levering
Wat je nodig hebt (kosten)
- Je hebt een sterke basis nodig voor continue integratie en je testsuite moet voldoende van je codebase dekken.
- Implementaties moeten geautomatiseerd worden. De trigger is nog steeds handmatig, maar zodra een implementatie is gestart, zou er geen menselijke tussenkomst nodig moeten zijn.
- Je team zal waarschijnlijk de functievlaggen moeten gaan gebruiken, zodat onvolledige functies geen gevolgen hebben voor klanten in de productie.
Wat je krijgt (baten)
- De implementatie van software is vereenvoudigd. Je team hoeft zich geen dagen meer voor te bereiden op een release.
- Je kunt vaker releases uitbrengen, waardoor de feedbackloop met je klanten wordt versneld.
- Er wordt veel minder druk uitgeoefend op beslissingen vanwege kleine veranderingen, waardoor het snellere iteratie stimuleert.
Continue implementatie
Wat je nodig hebt (kosten)
- Je testcultuur moet optimaal functioneren. De kwaliteit van je testsuite bepaalt de kwaliteit van je releases.
- Je documentatieproces moet de implementaties kunnen bijhouden.
- Functievlaggen worden een vast onderdeel van het proces waarbij belangrijke wijzigingen worden doorgevoerd om ervoor te zorgen dat je met andere afdelingen (support, marketing, PR ...) kunt coördineren.
Wat je krijgt (baten)
- Je kunt sneller ontwikkelen omdat je de ontwikkeling niet hoeft te onderbreken voor releases. Pipelines voor implementatie worden automatisch geactiveerd bij elke wijziging.
- Releases zijn minder riskant en eenvoudiger op te lossen in geval van problemen wanneer je kleine batches met wijzigingen implementeert.
- Klanten zien een continue stroom aan verbeteringen en de kwaliteit neemt elke dag toe, in plaats van elke maand, kwartaal of jaar.
Een van de traditionele kosten die gepaard gaan met continue integratie is de installatie en het onderhoud van een CI-server. Maar je kunt de kosten van deze praktijken toepassen aanzienlijk verlagen door gebruik te maken van een cloudservice zoals Bitbucket Pipelines die automatisering toevoegt aan elke Bitbucket-repository. Door simpelweg een configuratiebestand toe te voegen aan de hoofdmap van je repository, kun je een doorlopende implementatiepipeline aanmaken die wordt uitgevoerd voor elke nieuwe wijziging die naar de main-branch wordt gepusht.
Van continue integratie naar continue implementatie
Als je net begint aan een nieuw project zonder gebruikers, dan is het misschien eenvoudig om al je commits in de productie te implementeren. Je zou zelfs kunnen beginnen met je implementaties automatiseren. Je kunt je alfaversie beschikbaar maken voor productie zonder klanten. Dan kun je je testcultuur verbeteren en ervoor zorgen dat je de codedekking verhoogt terwijl je je toepassing ontwikkelt. Tegen de tijd dat je klaar bent om gebruikers te accepteren, zul je een geweldig continu implementatieproces hebben waarbij alle nieuwe wijzigingen worden getest voordat ze automatisch in productie worden genomen.
Maar als je al een bestaande toepassing bij klanten hebt, moet je het rustig aan doen en beginnen met continue integratie en continue levering. Begin met de implementatie van eenvoudige unittest die automatisch worden uitgevoerd. Je hoeft je nog niet te concentreren op het uitvoeren van complexe end-to-end-tests. In plaats daarvan moet je proberen je implementaties zo snel mogelijk te automatiseren en zo een fase bereiken waarin de implementaties in je testomgevingen automatisch worden uitgevoerd. De reden is dat als je automatische implementaties hebt, je je energie kunt richten op het verbeteren van je tests in plaats van af en toe dingen stop te zetten om een release te coördineren.
Als je eenmaal dagelijks kunt beginnen met het releasen van software, kun je kijken naar continue implementatie. Maar zorg ervoor dat de rest van je organisatie er klaar voor is: documentatie, support, marketing, enz. Deze functies moeten aangepast worden aan het nieuwe aantal releases, en het is belangrijk dat ze geen belangrijke wijzigingen missen die gevolgen kunnen hebben voor klanten.
Lees onze handleidingen
Read our guides
Je kunt verschillende gedetailleerdere handleidingen vinden om je te helpen aan de slag te gaan met deze praktijken.
Deel dit artikel
Volgend onderwerp
Aanbevolen artikelen
Bookmark deze resources voor meer informatie over soorten DevOps-teams of voor voortdurende updates over DevOps bij Atlassian.
DevOps-community
Blog lezen
