L'intégration continue à l'ère du cloud: stratégies et outils
CI dans le cloud : adapter ses pipelines à chaque provider
L'intégration continue dans le cloud n'est pas la même que la CI sur un serveur Jenkins local. Le cloud apporte des contraintes spécifiques (latence réseau, gestion des credentials, coûts variables) mais aussi des opportunités (scaling illimité, services managés, intégration native). Après avoir mis en place des pipelines CI sur AWS, GCP, Azure, OVH et Scaleway, voici mon retour d'expérience.
CI sur AWS : l'écosystème le plus complet
Chez F2R2, avec l'architecture AWS Multi-Compte et 25 modules Terraform, le pipeline CI devait pouvoir assumer plusieurs rôles IAM pour planifier les changements sur différents comptes. Nous avons utilisé GitHub Actions avec OIDC pour authentifier les workflows sans stocker de clés AWS statiques. Le workflow assume un rôle IAM différent pour chaque étape : un rôle read-only pour le terraform plan, un rôle admin pour le terraform apply (uniquement sur main).
Chez TEKYN sur AWS, la CI construisait les images Docker et les poussait sur ECR. L'astuce pour réduire les temps de build : le cache Docker en layer sur ECR. Chaque build réutilise les couches précédentes, ce qui divise le temps de build par 3 pour les changements mineurs.
CI sur GCP : la simplicité de GKE
Chez Okeiro sur GKE Autopilot, la CI utilisait GitHub Actions avec Workload Identity Federation pour s'authentifier auprès de GCP. Ce mécanisme élimine totalement les clés de service account JSON, qui sont une source majeure de fuites de credentials. Le workflow pousse l'image sur Artifact Registry et met à jour le Helm Chart dans le repo GitOps. ArgoCD sur GKE fait le reste.
L'avantage de GCP pour la CI : Cloud Build offre des builders optimisés avec un cache par défaut. Mais sur mes projets, je préfère garder GitHub Actions comme outil CI unique pour éviter la dispersion entre plusieurs outils.
CI et Infrastructure as Code : tester avant de déployer
Un aspect critique de la CI dans le cloud est le test de l'Infrastructure as Code. Chez Bloomflow, chaque PR modifiant du Terraform déclenchait automatiquement un terraform plan avec les résultats postés en commentaire sur la PR. Les reviewers pouvaient voir exactement ce qui allait changer avant d'approuver.
Pour aller plus loin, j'utilise des outils comme tfsec (analyse statique des configurations Terraform pour détecter les mauvaises pratiques de sécurité) et checkov (vérification de conformité). Ces outils s'intègrent directement dans le pipeline GitHub Actions et bloquent le merge en cas de non-conformité.
Le coût de la CI dans le cloud
Le coût des runners CI est un sujet souvent négligé. Chez Bloomflow, avec 15 microservices et 5 développeurs actifs, la facture GitHub Actions (runners hébergés) atteignait 800 euros par mois. En passant à des self-hosted runners sur des instances Spot AWS (70% moins cher que le on-demand), nous avons réduit cette facture à 200 euros.
Chez Coopengo, les runners Jenkins tournaient sur des instances Spot AWS, ce qui a réduit le coût du CI de 30%. Le compromis : les Spot peuvent être interrompues. Nous avions configuré Jenkins pour relancer automatiquement les jobs interrompus sur une nouvelle instance.
La CI multi-cloud : un cas réel
Chez Bloomflow, avec des déploiements sur AWS, Scaleway et Outscale, le pipeline CI devait construire une seule image Docker mais la pousser sur trois registres différents (ECR pour AWS, Container Registry pour Scaleway, registre Docker pour Outscale). Le workflow GitHub Actions utilisait une matrice pour paralléliser les push. Cela ajoutait 2 minutes au pipeline mais garantissait que l'image était disponible sur tous les providers avant que ArgoCD ne déclenche les déploiements.