Les problèmes du staging
- le pré-live n’est pas identique à la production
- une file d’attente de release se crée
- les releases deviennent trop importantes
- manque de responsabilisation vis-à-vis des changements
- on laisse le processus se substituer à la responsabilité
Comment Squeaky met en production
- ne merger que ce qui est prêt pour le live : les changements sont suffisamment testés dans l’environnement de développement local
- utiliser une stratégie de branches plates : quand une fonctionnalité est prête à être mergée, rebase puis test. En cas de problème, roll forward
- les fonctionnalités à haut risque utilisent toujours des feature flags
- déploiement manuel : surveillance continue après les changements. Monitoring / logging / alerting appliqués de manière globale. Déploiement blue/green
Conclusion
- renoncer à l’environnement de staging pour un véritable CI/CD permet d’adopter une autre façon de penser la mise en production du logiciel
- s’il n’y a pas de tampon avant qu’un changement passe en live, il faut avoir la certitude qu’il est adapté à la production
- il faut assumer la responsabilité de tous les changements que l’on apporte et y prêter une attention constante
- cela réduit les coûts et la complexité de l’infrastructure, et permet de simplifier et d’accélérer le cycle de développement
3 commentaires
En repensant au sentiment de sécurité que j’ai ressenti en mettant en place un environnement de staging au sein d’une organisation, j’ai du mal à vraiment être d’accord.
Cela dit, je comprends bien les inconvénients, comme le fait que les déploiements prennent du retard ou que les changements s’accumulent.
Je pense que le simple fait qu’un environnement de staging existe a déjà du sens, car cela permet de vérifier qu’on peut déployer dans un autre environnement et que l’on satisfait à la nature même d’un logiciel qui peut être répliqué.
Eh bien, je ne sais pas s’il faut vraiment s’en remettre à des personnes dont l’« ownership » / l’« attention » sont imparfaits. Au minimum, en tant que programmeurs informatiques, n’est-ce pas notre rôle de nous faire aider par des ordinateurs qui, eux, fonctionnent parfaitement comme on le leur demande ?
Et en élargissant le concept :
staging = pour la validation finale (vérifier que c’est bien conforme aux specs dont on avait parlé, ou constater qu’avec les données produit réelles, le rendu est moins bon que prévu, etc.)
dev = pour discuter avec les développeurs et autres personnes des features (démo)
Hum... je pense que ce genre de problème dépend du type de service que l’on développe.
Même en testant autant qu’on veut, des problèmes peuvent survenir, et il faut se demander si les utilisateurs peuvent l’accepter.
Pour un logiciel comme Facebook, où même s’il dysfonctionne on se dit simplement « bon, tant pis », ce genre d’approche peut fonctionner,
mais s’il s’agit d’une infrastructure critique ou d’un service payant, il faut sans doute tout faire pour éviter que des problèmes ne surviennent.