Release, mise en production et déploiement

De l'importance du sens des mots. Découpler les activités de planification à moyen terme (release) de celles pour livrer aux utilisateurs finaux (mise en production) et de celles techniques (déploiement).

Dans le glossaire de mon livre Scrum, édition 4, je définis une release ainsi :

Release : période de temps constituée d’une série de sprints aboutissant généralement à déployer une version du produit.

Ailleurs dans le livre, je développe l'idée qu'une release n'est pas à confondre avec une mise en production, notamment dans le chapitre 2 (pages 20 et 21) et aussi dans le chapitre 16, qui s'appelle Planifier la release.

Cependant, ces notions sont encore confondues. Il est vrai que l'utilisation que je fais de release n'est pas celle la plus connue et que la deuxième partie de ma définition n'est pas assez précise, avec généralement.

Mes lectures récentes (Lean Entreprise) me poussent à différencier aussi mise en production et déploiement.

Voici mes nouvelles définitions :

  • Une release est une période de temps constituée d’une série de sprints.
  • Une mise en production est l'action de procurer de la valeur aux utilisateurs (valeur métier)
  • Un déploiement est l'action d'installer du logiciel sur un environnement, pour apprendre quelque chose (valeur d'apprentissage).

Quelques précisions :

  • Le choix de la durée de la release, de ce qu'on y fait à la fin, fait partie des décisions de fonctionnement de l'équipe (comme la durée du sprint). Il est maintenant d'usage que cette durée soit fixe (la même pour toutes les releases), pour profiter d'un rythme régulier.
  • Mettre en production concerne le produit, c'est donc au Product Owner qu'incombe la décision (il consulte pour cela, niveau 3 de la délégation dans Management3.0). Plus on devient agile, plus on peut mettre en production souvent.
  • Une mise en production inclut un déploiement sur l'environnement de production.
  • La décision de déployer (sur un environnement autre que production) est faite par l'équipe. Comme on cherche à apprendre le plus vite possible, on se mettra en situation de pouvoir déployer au plus vite.

Un exemple pour une équipe, qui illustre le découplage de ces 3 notions :

  • La release dure 3 mois, avec 6 sprints de 2 semaines. En fin de release sont placés : une rétrospective plus poussée, un forum ouvert et la préparation du prochain plan de release. Quatre fois par an.
  • La mise en production a lieu à chaque fois qu'une feature est finie.
  • Le déploiement sur l'environnement de staging a lieu à chaque fois qu'une story est finie.

Merci pour votre feedback et vos exemples.


Feedback de Samuel Rétière le 9 novembre, qui me permet d'approfondir sur le découplage entre déploiement et mise en production

Le déploiement sur un environnement de production n'induit pas forcément une mise en production telle que je la définis. En effet, il est possible de déployer en protégeant des features (avec des "flags") de telle sorte qu'elles ne soient pas visibles ou visibles seulement par un groupe restreint d'utilisateurs.

Dans Lean Entreprise, une autre technique pour déployer en environnement de production sans mettre en production est présentée : bleu-green deployment