Continue integratie instellen
Ontdek hoe je continue integratie en geautomatiseerde tests toepast in 5 stappen.
Sten Pittet
Mede-auteur
Continue integratie (CI) is een agile en DevOps best practice waarbij ontwikkelaars hun codewijzigingen vroeg en vaak integreren in de hoofdbranch of de coderepository. Het doel is het voorkomen van een “integratiehel” waarbij gewacht wordt tot het einde van een project of een sprint om het werk van alle ontwikkelaars samen te voegen. Omdat het de implementatie automatiseert, helpt het teams om aan zakelijke vereisten te voldoen, de codekwaliteit te verbeteren en de beveiliging te verhogen.
Een van de belangrijkste voordelen van het adopteren van CI is dat het je tijd bespaart tijdens je ontwikkelingscyclus door conflicten vroegtijdig te identificeren en aan te pakken. Het is ook een geweldige manier om minder tijd te besteden aan het oplossen van bugs en regressie door meer nadruk te leggen op een goede testsuite. Tot slot helpt het om een beter begrip te krijgen van de codebase en de functies die je ontwikkelt voor je klanten.
De eerste stap naar continue integratie: het opzetten van geautomatiseerde tests.
Aan de slag met geautomatiseerd testen
Inzicht in de verschillende soorten tests
Om alle voordelen van CI te kunnen benutten, moet je je tests automatiseren om ze te kunnen uitvoeren voor elke wijziging die wordt aangebracht in de hoofdrepository. We dringen erop aan om tests uit te voeren op elke branch van je repository en je niet alleen te concentreren op het hoofdbranch. Op deze manier kun je problemen vroegtijdig opsporen en onderbrekingen voor je team tot een minimum beperken.
Er zijn veel soorten tests geïmplementeerd, maar het is niet nodig om alles tegelijk te doen als je net begint. Je kunt klein beginnen met unittests en eraan werken om je dekking in de loop van de tijd uit te breiden.
- Unittests hebben een beperkte scope en verifiëren over het algemeen het gedrag van individuele methoden of functies.
- Integratietests zorgen ervoor dat meerdere componenten zich op de juiste manier gedragen. Dit kan verschillende klassen omvatten, maar ook om het testen van de integratie met andere services.
- Acceptatietests zijn vergelijkbaar met de integratietests, maar ze richten zich op de business cases in plaats van op de componenten zelf.
- UI-tests zullen ervoor zorgen dat de applicatie correct werkt vanuit het perspectief van de gebruiker.
Oplossing bekijken
Software bouwen en gebruiken met Open DevOps
Gerelateerd materiaal
Meer informatie over geautomatiseerd testen
Niet alle tests zijn gelijk, en je kunt uitwerken welke afwegingen je zult maken met de testpiramide die is ontwikkeld door Mike Cohn.
Unittests zijn snel en goedkoop uit te voeren, omdat ze meestal kleine stukjes code controleren. Aan de andere kant zullen UI-tests complex zijn om te implementeren en traag om uit te voeren, omdat ze vaak een volledige omgeving moeten starten en er meerdere services nodig zijn om browser- of mobiel gedrag na te bootsen. Daarom wil je misschien het aantal complexe UI-tests beperken en vertrouwen op een basis van goede unittests voor een snelle build en om zo snel mogelijk feedback te krijgen van ontwikkelaars.
Voer je tests automatisch uit
Om voor continue integratie te kiezen, moet je testen op elke wijziging die terug wordt gepusht naar de branch. Daarvoor heb je een service nodig die je repository in de gaten kan houden en kan luisteren naar nieuwe pushes naar de codebase. Er zijn veel oplossingen waaruit je kunt kiezen, zowel on-premise als in de cloud. Je moet rekening houden met het volgende wanneer je je server kiest:
- Waar wordt je code gehost? Heeft de CI-service toegang tot je codebase? Heb je een speciale beperking met betrekking tot waar de code mag worden opgeslagen?
- Welk besturingssysteem en welke bronnen heb je nodig voor je applicatie? Wordt jouw toepassingsomgeving ondersteund? Kun je de juiste afhankelijkheden installeren om je software te maken en te testen?
- Hoeveel bronnen heb je nodig voor je tests? Voor sommige cloudtoepassingen gelden mogelijk beperkingen wat betreft de bronnen die je kunt gebruiken. Als je software veel bronnen verbruikt, kun je je CI-server beter achter je firewall hosten.
- Hoeveel ontwikkelaars heeft je team? Als je team CI gebruikt, worden er elke dag veel wijzigingen gepusht naar de hoofdrepository. Om ervoor te zorgen dat de ontwikkelaars snel feedback krijgen, moet je de wachttijd voor de builds verkorten, en je zult een service of server willen gebruiken die je de juiste tijd biedt.
In het verleden moest je meestal een aparte CI-server installeren, zoals Bamboo of Jenkins, maar nu kun je in de cloud oplossingen vinden die veel eenvoudiger te implementeren zijn. Als je code bijvoorbeeld wordt gehost op Bitbucket Cloud, kun je de pipelines-functie in je repository gebruiken om elke push te testen zonder dat je een aparte server of buildagent hoeft te configureren, en zonder beperking wat betreft gelijktijdigheid.
image: node:4.6.0 pipelines: default: - step: script: - npm install - npm testVoorbeeld van een configuratie om een Javascript-repository te testen met Bitbucket Pipelines.
Gebruik codedekking om een niet-geteste code te vinden
Als je eenmaal gebruikmaakt van geautomatiseerd testen, is het een goed idee om dat te koppelen aan een testdekkingstool die je een idee geeft van hoeveel van je codebase wordt gedekt door je testsuite.
Het is goed om te streven naar een dekking van meer dan 80%, maar pas op dat je een hoog dekkingspercentage niet verwart met een goede testsuite. Een hulpmiddel voor de dekking van de code helpt je om niet-geteste code te vinden, maar uiteindelijk zal de kwaliteit van je tests het verschil maken.
Als je nog maar net bent begonnen, haast je dan niet om 100% dekking van je codebase te krijgen, maar gebruik in plaats daarvan een testdekkingstool om uit te zoeken welke cruciale onderdelen van je aanvraag nog niet zijn getest en begin daar.
Refactoring is een kans om tests toe te voegen
Als je op het punt staat belangrijke wijzigingen aan te brengen in je applicatie, moet je beginnen met het schrijven van acceptatietests voor de functies die van invloed kunnen zijn. Dit biedt je een vangnet om ervoor te zorgen dat het oorspronkelijke gedrag niet is beïnvloed nadat je de code hebt aangepast of nieuwe functies hebt toegevoegd.
Kritieke succesfactoren bij de invoering van continue integratie
Hoewel het automatiseren van je tests een belangrijk onderdeel is van CI, is het op zichzelf niet voldoende. Het kan zijn dat je de cultuur van je team moet veranderen om ervoor te zorgen dat ontwikkelaars niet dagenlang aan een functie werken zonder hun wijzigingen samen te voegen met de main-branch, en dan moet je een green build-cultuur handhaven.
Integreer vroeg en vaak
Of je nu gebruik maakt van de trunk-gebaseerde ontwikkeling of van feature branches, het is belangrijk dat ontwikkelaars hun wijzigingen zo snel mogelijk integreren in de hoofdrepository. Als je de code te lang op een branch of op het werkstation van de ontwikkelaar laat staan, dan loop je het risico dat je te veel conflicten krijgt om naar te kijken als je besluit om dingen weer samen te voegen naar de hoofdbranch.
Door vroegtijdig te integreren, verklein je de scope van de wijzigingen, waardoor het makkelijker wordt om conflicten te begrijpen wanneer je ze hebt. Het andere voordeel is dat het makkelijker wordt om kennis te delen tussen ontwikkelaars, omdat ze meer verteerbare veranderingen krijgen.
Als je merkt dat je wijzigingen aanbrengt die gevolgen kunnen hebben voor een bestaande functie, kun je functievlaggen gebruiken om wijzigingen in de productie uit te schakelen totdat je werk klaar is.
Houd de build ten allen tijde groen
Als de build van de hoofdbranch door een ontwikkelaar niet langer werkt, wordt het oplossen ervan de belangrijkste prioriteit. Hoe meer wijzigingen er in de build worden aangebracht terwijl deze kapot is, hoe moeilijker het voor je wordt om te begrijpen waarom de build kapot is. En je loopt ook het risico dat er nog meer fouten optreden.
Het is de moeite waard om tijd te besteden aan je testsuite om er snel achter te komen wanneer het snel uitvalt en om feedback te geven aan de ontwikkelaar die de wijzigingen heeft doorgevoerd. Je kunt je tests opsplitsen zodat de snelle tests (bijvoorbeeld unittests) vóór de langere tests worden uitgevoerd. Als het altijd lang duurt voordat je testsuite faalt, verspil je veel tijd voor ontwikkelaars, omdat ze van context moeten veranderen om terug te gaan naar hun eerdere werk en het probleem op te lossen.
Vergeet niet om meldingen in te stellen om ervoor te zorgen dat ontwikkelaars op de hoogte worden gebracht wanneer de build faalt, je kunt ook nog een stap verder gaan door de status van je belangrijkste branches weer te geven op een dashboard waar iedereen deze kan zien.
Schrijf tests als onderdeel van je story's
Tot slot moet je ervoor zorgen dat elke functie die wordt ontwikkeld, automatisch wordt getest. Het lijkt er misschien op dat je de ontwikkeling zo vertraagt, maar in werkelijkheid zal dit de tijd die je team besteedt aan het oplossen van regressie of bugs die in elke iteratie zijn geïntroduceerd, drastisch verminderen. Je zult ook met een gerust hart wijzigingen kunnen aanbrengen in je codebase, aangezien je testsuite er snel voor kan zorgen dat alle eerder ontwikkelde functies naar verwachting werken.
Om goede tests te schrijven, moet je ervoor zorgen dat ontwikkelaars in een vroeg stadium worden betrokken bij de definitie van de userstory's. Dit is een uitstekende manier om een beter gedeeld inzicht te krijgen in de zakelijke vereisten en om de relatie met productmanagers te faciliteren. Je kunt zelfs beginnen met het schrijven van de tests voordat je de code implementeert die aan de tests voldoet.
Schrijf tests tijdens het oplossen van bugs
Of je nu een bestaande codebase hebt of net begonnen bent, het is zeker dat er bugs zullen optreden als onderdeel van je releases. Zorg ervoor dat je tests toevoegt wanneer je ze oplost, om te voorkomen dat ze zich opnieuw voordoen.
CI stelt je QA-ingenieurs in staat om de kwaliteit op te schalen
Een andere rol die zal veranderen met de invoering van CI en automatisering is de rol van de QA-ingenieur. Ze hoeven niet langer handmatig de triviale mogelijkheden van je applicatie te testen en ze kunnen nu meer tijd besteden aan het leveren van tools om ontwikkelaars te ondersteunen en hen te helpen de juiste teststrategieën toe te passen.
Zodra je continue integratie begint toe te passen, kunnen je QA-ingenieurs zich concentreren op het faciliteren van tests met betere tools en datasets en kunnen ze ontwikkelaars helpen om betere code te schrijven. Er zullen nog enkele verkennende tests worden uitgevoerd voor complexe toepassingen, maar dit zou een minder prominent onderdeel van hun werk moeten zijn.
Continue integratie instellen in 5 stappen
Je zou nu een goed idee moeten hebben van de concepten achter continue integratie, en we kunnen het met deze lijst samenvatten:
- Begin met het schrijven van tests voor de kritieke onderdelen van je codebase.
- Zorg voor een CI-service om die tests automatisch uit te voeren bij elke push naar de hoofd-repository.
- Zorg ervoor dat je team hun wijzigingen elke dag integreert.
- Repareer de build zodra deze kapot is.
- Schrijf tests voor elke nieuw story die je implementeert.
Hoewel het er misschien eenvoudig uitziet, is echte toewijding van je team vereist om effectief te zijn. In het begin moet je releases wat langzamer uitbrengen, en je hebt steun nodig van de producteigenaren om ervoor te zorgen dat ze ontwikkelaars niet overhaasten om functies te leveren zonder tests.
Onze aanbeveling is om klein te beginnen met eenvoudige tests om te wennen aan de nieuwe routine, voordat we overgaan tot de implementatie van een complexere testsuite die misschien moeilijk te beheren is.
Meer informatie over continue integratie met Bitbucket Pipelines. En als je een DevOps-toolchain wilt bouwen, bekijk dan Open DevOps, dat integraties met toonaangevende leveranciers en marketplace-apps omvat.
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
