Hotfixes met Docker-artifacts in een Git Flow-strategie

Deze post is een vervolg op GIT deployment-strategieën binnen Kubernetes-omgevingen. Lees eerst deze post:

CI/CD pipeline with Docker and Git branching strategyExplore advanced CI/CD with Docker & Git. Master deploying Docker artifacts via Git branching. Dive into strategies for DEV, STAGING, LIVE environments. Perfect your pipeline now!All Subjects MatterRemco Loup.

In een CI/CD-pipeline die draait om Docker artifacts, met de focus op één enkele branch, vraagt een efficiënte hotfix-strategie om een kleine afwijking van de standaardaanpak. Zo zorgen we dat kritieke fixes snel gedeployd worden. Laten we onze aanpak voor hotfixes in deze Docker-gerichte omgeving uitwerken, op basis van de branch-architectuur uit de post hierboven.

Wanneer is een hotfix nodig?

Hotfixes zijn cruciaal voor de stabiliteit en betrouwbaarheid van elke software in productie. Ze zijn meestal nodig in situaties die directe actie vragen. Weten wanneer je een hotfix inzet, is essentieel om je CI/CD-pipeline goed te beheren, zeker als je werkt met Docker artifacts en een gestroomlijnde branch-strategie met één hoofdbranch. Dit zijn onze scenario’s waarin een hotfix nodig kan zijn:

1. Beveiligingslekken: Een van de meest urgente redenen voor een hotfix is het ontdekken van een beveiligingslek in je applicatie. Of het nu gaat om blootgestelde data, risico op ongeautoriseerde toegang of een andere kwetsbaarheid die kwaadwillenden kunnen misbruiken: je moet snel handelen om het lek te dichten en je gebruikers en data te beschermen.
2. Kritieke bugs die de gebruikerservaring raken: Als een serieuze bug door je testproces heen glipt en in productie belandt, kan dat de gebruikerservaring flink raken. Dat kan van alles zijn: een kapotte kernfunctionaliteit waardoor gebruikers de applicatie niet meer kunnen gebruiken, of ernstige performanceproblemen die leiden tot timeouts of crashes. Raakt het probleem een groot deel van je gebruikers? Dan is een hotfix op zijn plaats.
3. Compliance-problemen: Sommige applicaties hebben te maken met wettelijke of regelgevende eisen. Als er een compliance-probleem wordt geconstateerd dat je juridische positie of de privacy van gebruikers kan raken, moet dat snel met een hotfix worden opgelost om boetes of verlies van vertrouwen te voorkomen.
4. Risico op dataverlies: Situaties waarin gebruikersdata verloren kan raken of corrupt kan worden, vragen om directe actie. Of het nu een fout is in hoe data wordt opgeslagen, bijgewerkt of opgehaald: deploy dan een hotfix om verlies of corruptie van gebruikersdata te beperken.
5. Falende betalingen of transacties: Voor applicaties die betalingen of andere transacties verwerken, zijn problemen die transacties blokkeren of tot financiële discrepanties leiden kritiek. Zulke problemen schaden niet alleen het vertrouwen van gebruikers, maar kunnen ook financiële gevolgen hebben voor zowel gebruikers als de dienstverlener. Een hotfix is dan noodzakelijk.

Een hotfix deployen

Als er een kritiek probleem in de productieomgeving wordt geconstateerd, is het doel om zo snel mogelijk een hotfix te ontwikkelen, testen en deployen. Omdat MAIN onze hoofdbranch voor development is en we Docker artifacts genereren voor deployment, hebben we een proces nodig dat snelle interventie mogelijk maakt zonder het lopende werk te verstoren.

1. Een hotfix-branch aanmaken: In plaats van te branchen vanaf je Production branch (LIVE bestaat in deze strategie immers niet meer in de Git-repository), maak je de hotfix-branch vanaf de commit die op dat moment in productie draait. Zo is de hotfix gebaseerd op exact de versie die in de productieomgeving draait. De specifieke commit vind je via tags of Docker image-labels die gekoppeld zijn aan de productie-deployment.
2. De hotfix ontwikkelen en testen: De kritieke fix wordt ontwikkeld binnen deze hotfix-branch. De urgentie vraagt om een gerichte aanpak: pak het probleem aan met minimale wijzigingen om testen en deployen te versnellen. Ook onder tijdsdruk is het naleven van de Definition of Done (DoD) cruciaal voor de stabiliteit en betrouwbaarheid van de hotfix. Dat kan een compactere versie van de DoD zijn, met prioriteit voor de kritieke tests en checks die garanderen dat de fix geen nieuwe problemen introduceert.
3. Een Docker artifact voor de hotfix maken: Zodra de hotfix aan de afgesproken DoD-criteria voldoet, bouwt een geautomatiseerd proces een Docker image van de hotfix-branch. Dit Docker artifact krijgt een passende tag, zodat duidelijk is waar het voor dient en hoe urgent het is.
4. De hotfix deployen: Het nieuwe Docker artifact wordt direct in de productieomgeving gedeployd, waarbij de gebruikelijke route via DEV en STAGING naar PRODUCTION wordt overgeslagen. Deze deployment is alleen te rechtvaardigen door de kritieke aard van de fix en de tests die erop zijn uitgevoerd.
5. Terugmergen en consistentie bewaken: Als de hotfix succesvol in productie draait, is het essentieel om de wijzigingen terug te mergen naar de MAIN branch en eventuele andere relevante branches of tags. Pas deze stap zorgt ervoor dat de fix wordt opgenomen in het lopende developmentwerk en toekomstige releases, en dat je geen regressie krijgt!!

Snel deployen en zo min mogelijk storing

• Geautomatiseerde processen: Automatisering speelt een sleutelrol in deze strategie, van het maken van het Docker artifact tot de deployment. Geautomatiseerde tests, builds en deployments zorgen dat het hotfix-proces zo snel en efficiënt mogelijk verloopt.
• Communicatie en monitoring: Snelle deployment van hotfixes vraagt om heldere communicatie binnen het team en nauwe monitoring van de productieomgeving na de deployment, om te verifiëren dat de fix werkt en geen nieuwe problemen introduceert.
• Documentatie en review: Het documenteren van het hotfix-proces en het doen van post-mortem-reviews helpt om de hotfix-strategie te verfijnen, zodat het team bij toekomstige problemen nog effectiever kan reageren.

Conclusie

In een CI/CD-pipeline met Docker en Git Flow als hoofdstrategie vraagt een hotfix om een strakke aanpak: gebruik de automatisering die er al is en focus op snelle, gerichte fixes. Door hotfix-branches te baseren op de commit die in productie staat, fixes te bouwen en testen volgens een goed gedefinieerde Definition of Done, en de Docker-artifacts direct naar productie te deployen, lost een team kritische problemen snel op zonder de stabiliteit en integriteit van de applicatie in gevaar te brengen.