Réduire le temps de déploiement avec GitHub Actions ?

Réduire le temps de déploiement avec GitHub Actions ?

Cet article présente différentes méthodes essayées pour raccourcir le temps de déploiement avec GitHub Actions, ainsi que l’expérience de résolution des problèmes rencontrés au cours du processus.

• À mesure que le temps de déploiement s’allongeait, cela a commencé à avoir un impact négatif sur la vitesse de développement et la productivité de l’équipe
• L’article explique comment plusieurs améliorations ont été mises en place pour résoudre ce problème, notamment le passage du processus de déploiement à un traitement parallèle et l’introduction de déclencheurs de build sélectifs

Situation du problème

• Le temps de déploiement avec GitHub Actions a progressivement augmenté, pour atteindre une moyenne de 27 minutes
• Cela a commencé à affecter la productivité du développement
• Le Frontend, l’Intro et le Backend étaient buildés et déployés de manière séquentielle, et avec le temps cette méthode est devenue inefficace, entraînant une hausse du temps de déploiement

Principales améliorations

• Introduction du traitement parallèle
  • Les tâches de déploiement du Frontend et du Backend, auparavant exécutées en série, ont été séparées en parallèle, réduisant le temps de déploiement de 27 à 18 minutes.
  • Au cours de ce processus, le code des workflows GitHub a également été modularisé
• Introduction de déclencheurs de build sélectifs
  • path-filter a été utilisé pour ne builder que les parties modifiées, mais des situations problématiques ont été identifiées lors des rollbacks
  • Au lieu d’utiliser l’approche path-filter, une option du workflow a été fournie afin que les développeurs puissent choisir les cibles de déploiement
• Stratégie d’utilisation des tags d’images Docker
  • La réutilisation des images Docker a permis de réduire le temps de déploiement de 18 à 15 minutes.
• Traitement parallèle du déploiement
  • La phase de déploiement a elle aussi été séparée pour permettre le traitement parallèle, réduisant encore davantage le temps total
• Séparation de l’Intro
  • Le build de la page d’introduction a été séparé, côté frontend, du build du service afin de maximiser l’efficacité du déploiement.

Résultats

• Réduction de 55 % du temps de déploiement (27 min -> 12 min)
• Jusqu’à 70 % de réduction possible, baisse des coûts d’infrastructure et amélioration de la productivité du développement produit.
• Avantages supplémentaires
  • La modularisation des workflows a amélioré la réutilisabilité et la facilité de maintenance
  • Réduction du temps de résolution des problèmes et amélioration de la stabilité du système