Optimiser son workflow DevOps avec GitHub Actions
Introduction
GitHub Actions a dépassé le cadre du simple CI/CD pour devenir un véritable outil d'automatisation DevOps. Au-delà des builds et des tests, je l'utilise pour orchestrer la gestion d'infrastructure, le monitoring, les notifications, et même la documentation. Voici les usages avancés que j'ai mis en place sur mes projets.
L'automatisation de la gestion des dépendances
Renovate ou Dependabot intégrés à GitHub Actions transforment la gestion des mises à jour. Sur WizOps.fr, Renovate crée automatiquement des PR pour chaque mise à jour de dépendance (npm, Docker, Helm). Le pipeline CI exécute les tests sur chaque PR Renovate. Si les tests passent et qu'il s'agit d'une mise à jour mineure ou patch, la PR est auto-mergée après 24 heures. Pour les mises à jour majeures, une review humaine est requise. Chez Bloomflow, cette approche a maintenu les 20 services à jour avec un effort humain minimal : environ 1 heure par semaine pour reviewer les mises à jour majeures, au lieu de la journée mensuelle de "mise à jour des dépendances" qui était systématiquement reportée.
Les workflows event-driven
GitHub Actions peut réagir à bien plus que des push et des PR. Chez Epiconcept, j'avais configuré des workflows déclenchés par des commentaires de PR : un développeur qui commentait /deploy staging déclenchait le déploiement sur staging, /run-perf-tests lançait les tests de performance, et /approve-prod déclenchait la promotion en production après vérification des permissions. Ce pattern de "ChatOps" via les commentaires de PR a simplifié les processus : pas besoin de switcher vers un autre outil ou dashboard. Les opérations sensibles (déploiement prod) nécessitaient un label posé par un maintainer en plus du commentaire.
L'Infrastructure as Code dans GitHub Actions
Au-delà de Terraform (que j'ai couvert en détail), GitHub Actions orchestre toute la gestion d'infrastructure. Chez TEKYN, le workflow d'infrastructure gérait : le provisionnement des clusters ECS Fargate via Terraform, la configuration des distributions CloudFront, la mise à jour des règles WAF, et le nettoyage des environnements de review périmés. Un workflow scheduled (cron) s'exécutait chaque nuit pour vérifier que les coûts AWS restaient dans les budgets définis, et créait une issue si un seuil était dépassé. Cette centralisation de toute la gestion d'infrastructure dans GitHub Actions a éliminé le besoin d'outils tiers comme Spacelift ou Terraform Cloud.
Les notifications et la communication
Les notifications bien configurées accélèrent la résolution des problèmes. Chez Metronome, j'avais configuré des notifications Discord granulaires : un canal pour les succès de déploiement (informatif, non bloquant), un canal pour les échecs de pipeline (requiert une action), et des mentions ciblées (@team-backend si le backend échoue). Le message incluait un lien direct vers les logs du job échoué, le nom de la PR, et l'auteur du commit. Chez Bloomflow, un rapport hebdomadaire généré par GitHub Actions compilait les métriques CI de la semaine (nombre de déploiements, taux de succès, temps moyen de pipeline) et le postait dans un canal Slack. Ce rapport a rendu visible l'amélioration continue de la qualité du pipeline.
La documentation automatisée
GitHub Actions peut générer et maintenir la documentation à jour. Chez F2R2, terraform-docs s'exécutait automatiquement sur chaque PR modifiant des modules Terraform et mettait à jour les README avec les inputs, outputs et exemples. Si la documentation n'était pas à jour, le pipeline échouait. Cette approche a éliminé la documentation obsolète qui affligeait le projet avant mon arrivée. De même, les diagrammes d'architecture étaient générés automatiquement à partir des manifestes Kubernetes (via Helm template et un outil de visualisation). Chaque merge dans main mettait à jour les diagrammes dans le wiki GitHub, garantissant qu'ils reflétaient toujours l'état réel de l'infrastructure.
Conclusion
GitHub Actions est un outil d'automatisation bien plus puissant qu'un simple CI/CD. Gestion des dépendances, ChatOps, Infrastructure as Code, notifications intelligentes et documentation automatisée sont autant d'usages qui transforment le workflow DevOps. La clé est de penser GitHub Actions comme une plateforme d'automatisation générale, pas juste comme un pipeline de build. Cette vision, appliquée sur mes projets, a systématiquement réduit le travail manuel et amélioré la qualité opérationnelle.