Accélérer le Déploiement Continu avec GitHub Actions
Du commit au déploiement en 10 minutes : mon pipeline GitHub Actions en production
Le déploiement continu avec GitHub Actions, ce n'est pas juste lancer un kubectl apply à la fin d'un workflow. C'est orchestrer l'ensemble de la chaîne, du push de code au déploiement en production, avec des garde-fous à chaque étape. Voici comment je structure mes pipelines CD sur mes projets.
L'architecture du pipeline type
Sur WizOps.fr, mon propre site, le pipeline de déploiement continu est le suivant : un push sur main déclenche le build Docker multi-plateforme avec Buildx, push les images vers GHCR (GitHub Container Registry), puis ArgoCD sur le cluster Kubernetes Scaleway détecte le nouveau tag et déploie automatiquement. Le tout prend environ 8 minutes du commit à la mise en production.
La clé est la séparation des responsabilités : GitHub Actions gère le build et le push des images. ArgoCD gère le déploiement sur Kubernetes. Cette séparation évite le couplage entre la CI et le cluster, et permet de changer l'un sans impacter l'autre.
Gestion des environnements avec GitHub Environments
Un pattern que j'ai mis en place chez Bloomflow pour sécuriser les déploiements : utiliser les GitHub Environments avec des règles de protection. Le déploiement en staging est automatique sur chaque merge dans main. Le déploiement en production nécessite une approbation manuelle par un membre de l'équipe. Les secrets (clés AWS, tokens Kubernetes) sont scopés par environnement, ce qui empêche un workflow de staging d'accéder aux credentials de production.
Chez Padam Mobility, nous avions poussé le concept plus loin avec des environnements de preview par Pull Request. Chaque PR déployait automatiquement une version isolée de l'application avec son propre namespace Kubernetes. Les reviewers pouvaient tester la fonctionnalité sur une URL dédiée avant d'approuver le merge. Le namespace était automatiquement nettoyé à la fermeture de la PR.
Le déploiement GitOps : GitHub Actions + ArgoCD
La combinaison que je déploie systématiquement depuis 3 ans : GitHub Actions pour le CI (build, test, push image) et ArgoCD pour le CD (déploiement Kubernetes). Le lien entre les deux est un commit automatique dans un repo GitOps qui met à jour le tag de l'image Docker.
Chez F2R2, ce pattern était déployé sur l'architecture AWS Multi-Compte : le workflow GitHub Actions buildait l'image, la poussait sur ECR, puis un job mettait à jour le fichier values.yaml du Helm Chart dans le repo GitOps. ArgoCD, installé sur le cluster EKS Fargate, détectait le changement et déployait. Chaque déploiement était tracé dans l'historique Git du repo GitOps, offrant un audit trail complet.
Notifications et monitoring post-déploiement
Un déploiement sans notification, c'est un déploiement qu'on oublie de surveiller. Sur tous mes projets, le workflow GitHub Actions envoie une notification Slack à la fin du déploiement avec le statut (succès/échec), le numéro du commit, et un lien vers les logs.
Chez Bloomflow, nous avions ajouté une étape de smoke test post-déploiement : un job qui attend 60 secondes après le déploiement, puis vérifie que les endpoints critiques répondent correctement (health check, page d'accueil, API principale). En cas d'échec, une alerte immédiate est envoyée et le rollback est déclenché automatiquement via ArgoCD.
Les erreurs qui m'ont coûté cher
La plus coûteuse : ne pas avoir mis de concurrency control sur un workflow CD. Deux développeurs ont mergé quasi simultanément, déclenchant deux déploiements en parallèle. Le second a écrasé le premier avant qu'il ne soit terminé, corrompant l'état de l'application. Depuis, j'utilise systématiquement concurrency: { group: "deploy-prod", cancel-in-progress: false } pour sérialiser les déploiements.