Mises en ligne automatisées pour une équipe produit
Une équipe produit montréalaise déployait à la main : chaque mise en ligne mobilisait un développeur senior pendant deux ou trois heures, et chaque release apportait son lot de surprises. On a refait le pipeline du commit au déploiement.
Chaque mise en ligne suivait un Google Doc de douze étapes manuelles. Un développeur senior bloquait deux à trois heures, vérifiait à la main que la base de données suivait, surveillait les logs, et croisait les doigts. Les déploiements partaient le mardi parce que personne ne voulait risquer un vendredi.
Le code et l'infrastructure dérivaient lentement. Trois outils d'IaC cohabitaient (Terraform hérité, scripts shell, console AWS). Personne ne savait quelle config était la source de vérité. Les environnements de staging et de production divergeaient sans qu'on s'en rende compte avant le prochain incident.
Le point de bascule : un correctif d'une ligne pour un bug client a pris deux jours à livrer parce qu'aucun chemin rapide n'existait. Le client avait raccroché avant la fin.
On déployait le mardi parce que personne ne voulait gérer ça un vendredi soir.
— Lead développeur
- 01Pipeline GitHub Actions completLint, tests unitaires, build, e2e Playwright, déploiement. Quatre jobs en parallèle, échec rapide. La même pipeline tourne sur chaque pull request avant le merge — plus rien n'arrive en main sans être passé par les gates.
- 02Environnements de prévisualisation par PRChaque pull request crée son propre environnement (URL unique, base de données fraîche, données de seed). Les revues de code se font sur du vrai produit, pas sur des captures d'écran. Détruit automatiquement à la fermeture de la PR.
- 03IaC unifiée avec PulumiMigration des trois outils précédents vers une seule base de code Pulumi + AWS CDK. Une source de vérité pour le réseau, les secrets, les bases de données, les certificats. Diff visible dans chaque PR avant d'être appliqué.
- 04Tableau de bord et alertes DatadogDashboards par service, alertes tied directement aux déploiements (annotation auto sur la timeline). Quand une métrique dérive après une release, l'équipe sait quel commit blâmer en quinze secondes.
- 05Bouton de rollback en un clicWorkflow GitHub manuel qui redéploie la version précédente. Testé chaque semaine via une chaos drill. Temps moyen de rollback mesuré : moins de deux minutes du clic au healthcheck vert.
Les mises en ligne sont passées de deux ou trois heures par semaine à environ huit minutes — sans personne devant l'écran. La cadence est passée de hebdomadaire à plusieurs déploiements par jour. Les vendredis sont redevenus des journées normales.
Le développeur senior qui orchestrait les déploiements a récupéré une journée complète par semaine. L'équipe ship des correctifs clients en moins d'une heure quand c'est urgent. Aucun incident de configuration drift depuis la migration.
On a livré un correctif urgent en douze minutes la semaine passée. Ça aurait pris deux jours il y a six mois.
— Lead développeur
- Les environnements de prévisualisation sont l'élément qui change tout — la revue de code devient une revue de produit.
- Un seul outil d'IaC, pas trois. Choisir et vivre avec les compromis coûte moins cher que de jongler.
- Lier les alertes aux déploiements transforme un dashboard passif en système d'alarme actif.