Optimisation des Déploiements avec GitHub Actions
Introduction
Mon passage de Jenkins a GitHub Actions s'est fait progressivement entre 2019 et 2021. Chez Epiconcept, ou je gerais Jenkins pour les projets INSERM et Armees, le serveur CI etait une VM dediee qui tombait en panne tous les trimestres, avec des plugins incompatibles a chaque mise a jour. Quand je suis arrive chez Bloomflow sur une feuille blanche, GitHub Actions venait de sortir de beta. Cinq ans et une centaine de workflows plus tard, c'est mon outil CI/CD de reference. Voici les patterns concrets que j'utilise pour optimiser les deploiements.
Anatomie d'un workflow bien structure
La premiere erreur que je vois chez mes clients : un fichier YAML monolithique de 500 lignes avec tout dedans. Sur le site wizops.fr, mon workflow est decoupe en jobs independants clairement separes : build frontend Nuxt, build backend Django, push des images Docker sur GHCR, puis deploiement Helm sur Scaleway Kubernetes. Chaque job a ses propres etapes, ses propres conditions d'echec, et ses propres artefacts. Si le build frontend echoue, le build backend continue. Le deploiement ne se lance que si les deux builds reussissent, grace a la directive needs.
Le build multi-plateforme (AMD64 + ARM64) avec Docker Buildx tourne sur un runner self-hosted equipe d'un SSD NVMe. Ce runner persiste le cache Docker entre les builds, ce qui divise le temps total par 3 par rapport aux runners GitHub heberges.
Les trois leviers d'optimisation du temps de build
Le caching est le premier levier. Sur WizOps, actions/cache avec une cle basee sur le hash du pnpm-lock.yaml reduit l'installation des dependances de 45 secondes a 5 secondes. Pour les builds Docker, le cache Buildx en mode gha (GitHub Actions cache) evite de rebuilder les layers qui n'ont pas change. Chez Epiconcept, ces optimisations ont fait passer les pipelines de 18 a 5 minutes apres la migration depuis Jenkins.
La parallelisation est le deuxieme levier. Les jobs lint, typecheck et tests s'executent simultanement. Le temps total est celui du job le plus lent, pas la somme. Chez Bloomflow, les 2000 tests etaient repartis en 4 shards paralleles, divisant le temps de test par 3.5.
Les runners self-hosted sont le troisieme levier. Pour WizOps, le runner self-hosted dispose du cache Docker local persistant. Le build complet frontend + backend + push GHCR prend 4 minutes, contre 12 sur un runner heberge. Chez Coopengo, les runners Jenkins tournaient deja sur des instances Spot AWS, reduisant la facture CI de 30%.
Securite des secrets dans les workflows
GitHub Actions offre des secrets au niveau repo et organisation. Chez Bloomflow, les secrets partages (credentials AWS, tokens registre Docker, cles de licence) etaient geres au niveau de l'organisation GitHub. Chaque repo heritait des secrets communs sans les dupliquer.
Un point critique : ne jamais logger un secret dans les outputs. J'ai decouvert chez un client que des tokens AWS apparaissaient en clair dans les logs de build, parce qu'un script d'initialisation faisait un echo sur les variables d'environnement pour le debug. Ma regle : utiliser ::add-mask:: pour les valeurs dynamiques sensibles, et auditer trimestriellement les permissions des GitHub Apps.
Chez F2R2, j'ai remplace les AWS Access Keys par OIDC (OpenID Connect). Le workflow assume un IAM role via OIDC sans stocker de credentials statiques. Plus de risque de fuite, plus de rotation de cles a gerer.
Deploiements multi-environnements avec les Environments
Les GitHub Environments sont sous-exploites. Chez F2R2, chaque compte AWS (dev, staging, prod) avait son Environment dedie. Le merge sur develop deployait en dev automatiquement. Le merge sur main deployait en staging. Un tag v* declenchait le deploiement en prod, avec une approbation manuelle obligatoire via les required reviewers de l'Environment. L'Environment prod stockait aussi ses propres secrets (ARN des roles IAM, endpoints Aurora), isoles des autres environnements.
Cette approche GitFlow adaptee offre une tracabilite complete : qui a deploye quoi, quand, et avec quelle approbation. Les auditeurs ISO 27001 chez Bloomflow appreciaient particulierement cette granularite.
Debugging et monitoring des workflows
Un workflow qui echoue silencieusement est pire qu'un qui echoue bruyamment. Sur tous mes projets, j'integre des notifications Discord ou Slack dans les pipelines. Chez Metronome, le canal Discord CI/CD recevait automatiquement le statut de chaque deploiement avec un lien vers le workflow et le commit concerne.
Pour le debugging avance, deux astuces : activer le debug logging via le secret ACTIONS_STEP_DEBUG pour des logs verbeux sans modifier le workflow, et utiliser tmate pour obtenir un shell SSH interactif dans le runner en cas de probleme complexe. Chez Epiconcept, cette technique m'a permis de diagnostiquer un probleme de permissions fichier dans un conteneur Docker que les logs seuls ne revelaient pas.
Conclusion
GitHub Actions a democratise le CI/CD en le rendant accessible directement depuis le repository. Sa force reside dans l'integration native avec GitHub, la marketplace riche en actions communautaires, et la flexibilite des runners self-hosted. Avec les trois leviers d'optimisation (caching, parallelisation, runners dedies) et une gestion rigoureuse des secrets, on obtient des pipelines de deploiement rapides, fiables et maintenables. C'est l'outil que je recommande systematiquement.