Optimisation de l'Intégration Continue avec Docker et GitHub Actions
Introduction
Docker et GitHub Actions sont les deux outils que j'utilise le plus au quotidien. Sur WizOps.fr, WizStatus, WizArmor, MongoAdmin.dev — chaque projet utilise ce duo. Après des centaines d'itérations, voici les optimisations qui font vraiment la différence.
Docker + GitHub Actions : le combo gagnant
Docker garantit que le code tourne dans le meme environnement partout. GitHub Actions orchestre le pipeline. Ensemble, ils éliminent deux catégories de problèmes : "ca marche chez moi" et "j'ai oublié de lancer les tests". Sur WizOps.fr, le workflow docker-image.yml utilise Docker Buildx pour des builds multi-plateforme (amd64/arm64) et les pousse vers GHCR. Les containers Docker de test reproduisent l'environnement de production. Chez Epiconcept, cette combinaison a fonctionné pendant 4 ans sur les projets INSERM sans incident lié au pipeline.
Configuration optimisée des containers de CI
Le Dockerfile de CI doit etre spécifiquement optimisé. Sur WizOps.fr, j'ai découvert qu'Alpine Linux nécessite des bindings musl pour certaines dépendances npm (comme oxc-parser) — un problème invisible en local sur Ubuntu. L'ordre des instructions est crucial : COPY package.json pnpm-lock.yaml ./ puis RUN pnpm install avant COPY . . pour que le cache des dépendances survive aux changements de code. Chez TEKYN, cette seule optimisation a réduit les rebuilds de 8 minutes a 90 secondes. Docker Compose en CI permet de monter des services compagnons (PostgreSQL, Redis) pour les tests d'intégration.
GitHub Actions : les workflows optimisés
Les workflows GitHub Actions doivent etre structurés pour la performance. Pattern que j'applique : les jobs parallélisables (lint, typecheck, tests unitaires) tournent en parallèle, le build Docker attend leur succès. Le cache est agressif : actions/cache pour le store pnpm (gain de 45 secondes sur WizOps.fr), Docker layer cache pour les builds (gain de 3 minutes chez TEKYN). Les runners self-hosted offrent 2x les performances des runners GitHub standard pour les builds Docker. Chez Bloomflow, la parallélisation des tests Vitest sur 4 workers réduisait le temps de 9 minutes a 3 minutes.
Tests automatisés dans les containers
Chez Bloomflow, les tests d'intégration tournaient dans des containers éphémères : PostgreSQL, Redis, Vault et l'application, orchestrés par docker-compose dans GitHub Actions. Chaque PR créait son environnement de test isolé, exécutait les tests, et nettoyait tout. Chez KNDS, les tests de sécurité (scan Trivy des images, vérification des NetworkPolicies) tournaient dans le pipeline avant tout déploiement. Sur WizOps.fr, les 51 tests Vitest utilisent happy-dom (pas de navigateur, donc pas de container lourd) pour un temps d'exécution minimal. Le choix du runner de test dépend du contexte : happy-dom pour le rendu, Playwright pour les tests e2e.
Surveillance et maintenance du pipeline
Un pipeline non surveillé se dégrade. Sur WizOps.fr, je vérifie régulièrement le temps d'exécution de chaque étape. Chez Bloomflow, un dashboard Grafana montrait le temps moyen de pipeline par semaine — toute dérive était investiguée. Les dépendances Docker et GitHub Actions doivent etre mises a jour régulièrement : Renovate automatise cette tache pour WizOps.fr. Les actions tierces doivent etre pinnées a un SHA spécifique pour la sécurité. Chez KNDS, chaque action GitHub utilisée était auditée avant d'etre autorisée dans le pipeline.
Conclusion
Docker + GitHub Actions est un duo éprouvé que j'utilise sur tous mes projets. Les optimisations clés : images Docker légères et bien cachées, workflows parallélisés, tests reproductibles dans des containers, et surveillance continue du pipeline. Chaque minute gagnée sur le pipeline est multipliée par le nombre de commits quotidiens — l'investissement dans l'optimisation est toujours rentable.