Tips en tricks voor een schaalbare CI/ CD flow
Wanneer er een project wordt gepland, is niet altijd duidelijk hoe groot het project uiteindelijk zal uitpakken. Het is daarom cruciaal om guidelines te volgen die het ontwikkelingsproces zo vloeiend mogelijk laten verlopen. Een bijzonder bruikbaar hulpmiddel hiervoor is een Continuous Integration/Delivery flow, oftewel CI/CD flow.
Bij aanvang van een typisch ontwikkeltraject, voordat een project gereed is voor publicatie, ziet een CI-flow er ongeveer als volgt uit:
Tijdens de development fase worden meer vervolgstappen aan het proces toegevoegd totdat het er ongeveer uitziet als op de onderstaande afbeelding. Echter, in sommige projecten kun je nog veel meer stadia tegenkomen dan deze. Bekijk hier de orginele afbeelding.
Deze blog laat een typische CI/CD-flow zien en voorziet in tips waarmee je dit voor grotere projecten kunt opschalen. Let op: deze aanbevelingen zijn gedaan in de veronderstelling dat de infrastructuur is ontwikkeld met behulp van Docker– en orkestratietools, zoals Kubernetes.
Bepaal je Version Control System (VCS)-workflow
Alle moderne CI-tools zijn afhankelijk van versiebeheersystemen, dus voor het instandhouden van de CI-flow op een hoog niveau dien je over een goede versiebeheersysteem te beschikken. Wij adviseren GitLab, Github Flow of Bitbucket om ideeën op te doen. Kies er één uit en pas je pipeline aan op basis van je behoeften.
GitHub flow: workflow strategieën
Aanbevelingen:
- Voer tests uit op elke push in elke branche. Hierdoor kunnen developers bugs sneller vinden en het proces voor het controleren van de code versnellen.
- Definieer branches die je gebruikt om Docker Image build processen te activeren en deze uit te rollen zoals weergegeven in de bovenstaande afbeelding.
- Mocht blijken dat releases een gecompliceerd handmatig goedkeuringsproces bevatten, gebruik dan tags om productiereleases in gang te zetten.
Specificeer je omgevingen
Zodra je een git-flow op zijn plaats hebt, integreer deze met de builds’ logic en pas deze aan voor het aantal omgevingen dat je voorhanden hebt. In eerste instantie zul je waarschijnlijk alles uitrollen naar productie na het testen van je lokale omgeving. Later kan je besluiten om development, acceptatietesten en productie uit te voeren.
Voorbeeld:
Regelmatig maken wij gebruik van een master branche om de uitrol naar de development omgeving te initiëren. Vervolgens mergen we de master branche tot de release branche. Dit triggert een uitrol naar acceptatietesten, waar een klein aantal gebruikers toegang krijgt tot de nieuwste versie. Indien alles correct werkt en het QA-team de release bevestigt, creëren we een tag van de release branch, die de implementatie van productie initieert.
Instellen van meldingen
Je dient alle processen van de CI-flow bij te houden via het notificatiekanaal waar je de voorkeur aan geeft. Wij gebruiken Slack voor onze projecten.
- Creëer een systeem notificatie channel en activeer het om meldingen over alle CI-en infrastructuur processen te versturen.
- Schakel meldingen in voor storingen en incidenten om je te waarschuwen wanneer de build wordt gestart.
Houd Docker images eenvoudig
In de praktijk is het beter om Docker image env-variabelen niet te gebruiken. Alle env-variabelen dienen via het Docker run command of via je orchestration tool niveau (bijvoorbeeld Kubernetes) te worden doorgegeven. Dit helpt om de CI-configuratiebestanden eenvoudiger te onderhouden.
Pipeline samenstellen
Bedrijven maken tegenwoordig steeds vaker gebruik van de microservices-architectuur; een unified pipeline ondersteunt hierbij door een snellere implementatie en configuratie van je CI in nieuwe microservices. Drone CI of Travis CI bieden tal van CI-omgevingsvariabelen (env) die je kunt toepassen tijdens de verschillende stappen van de pipeline. Hier volgen enkele voorbeelden van CI env-variabelen in de praktijk:
- Om een Docker-image te taggen kun je een aaneenschakeling van een build branche en build nummer gebruiken. Het resultaat is zoiets als “master-6.” Als alternatief is het mogelijk om je Git tag versie te gebruiken.
- Gebruik een repository naam voor deployments in je orchestratietools. Hieronder vind je een voorbeeld van Drone CI-implementatie naar Kubernetes cluster met env-variabelen.
image: peloton/drone-k8s-deployment
deployment_names: “${DRONE_REPO_NAME}”
container_names: “${DRONE_REPO_NAME}”
namespaces: microservices
docker_image: “62673275295.dkr.ecr.eu-west-1.amazonaws.com/${DRONE_REPO_NAME}:${DRONE_COMMIT_BRANCH}-${DRONE_BUILD_NUMBER}”
date_label: deployment.drone.io/date-deployed
secrets: [kubernetes_url, kubernetes_token]
Definieer naam conventies voor Docker Images
Een strategie voor de naamgeving van Docker-images moet gedefinieerd worden op basis van de specifieke kenmerken en het belang van de omgeving. Bijvoorbeeld, in ontwikkelings- en acceptatietest omgevingen waar je geen rollback functionaliteit nodig hebt, is het mogelijk om branch names te gebruiken als een tag, zodat alle nieuwe builds de vorige image overschrijven. Voor productie is het beter om images te taggen met het versienummer van de release (v1.0.0), wat de structuur en leesbaarheid van het register verbetert door de grootte ervan te verkleinen.
Gebruik Builder patronen
Indien het mogelijk is om iets op CI-niveau te compileren en te bouwen, kan het nuttig zijn om dit als een extra stap te realiseren, alvorens het uiteindelijk in de image te plaatsen. Bekijk deze video om een beter inzicht te verkrijgen.
Kubernetes Best Practices
DB Migraties als een afzonderlijke stap
Voer geen migratie uit als onderdeel van je Dockerfile, in plaats daarvan, doe het in een afzonderlijke stap. Extra commando’s, zoals het samenstellen van eigendommen of migraties, moeten als afzonderlijke stappen worden uitgevoerd. Probeer ook om Docker-images in de kortst mogelijke tijd up en running te brengen.
Vermijd privébibliotheken en submodules
Eventuele extra afhankelijkheden, zoals privé npm-modules of submodules, kunnen voor problemen zorgen tijdens het installatieproces van de CI-configuratie. Bijvoorbeeld, als er een submodule is en je CI heeft standaard alleen toegang tot je repositories via http en een autorisatietoken, dan zal je configuratie voor de lokale machine via Git niet werken. De submodule moet worden overruled en niet alle CI-tools leveren deze mogelijkheid.
Vergelijkbare problemen zullen zich voordoen als je privé npm-modules gebruikt, aangezien passkeys vereist zijn of modules die al gedownload zijn in de Docker Image.
In het kort
Wanneer een CI voor een nieuw project wordt geconfigureerd, besteed dan enige tijd aan het nadenken over en het definiëren van naamconventies, mogelijke methoden om te groeien en het unificeren van de building steps. Dit draagt uiteindelijk bij aan een snellere inzet van nieuwe diensten en services (kortere time-to-market. Het toepassen van dergelijke praktijken als basis voor nieuwe projecten bevordert tevens het sneller inwerken van medewerkers in het proces van de gehele pipeline.
Klaar om een CI/CD-pijplijn te implementeren of te verbeteren? Neem dan contact op met Axxius via het onderstaande contactveld.
