Sujet complexe et parfois même épineux au sein des équipes agiles qui ont une stack encore peu stable : est-ce qu’on fait une mise en production pour être « done » ? Si la réponse n’est en fait pas si complexe, nous allons voir que d’autres problèmes vont se rajouter à cette question.
Quand faire la mise en production
Il existe différentes façons de faire des mises en production dont celles que je vais citer ci-dessous :
- Déploiement continue : tout se déploie automatiquement sans même passer par des tests humains avec une capacité de rollback automatique. C’est la Royce Rolls des mises en production
- Livraison par release : on ne livre que quand on a un lot de fonctionnalités à livrer et testé.
- Livraison en fin de sprint (voire le lundi matin si le sprint se termine vendredi) : c’est une façon de faire encore très répandue où on fait une livraison complète de ce qui est « done » à chaque fin de sprint.
- Livraison continue : on livre à chaque fois qu’une demande passe en « done ».
Il existe d’autres stratégies de déploiement mais j’ai tenté de vous citer les 4 principales que l’on rencontre aujourd’hui sur le marché dans plus de 99% des cas.
Est-ce que la livraison est obligatoire pour la Definition of Done ?
Maintenant, doit-on livrer nos demandes pour qu’elles soient considérées terminées soient « Done » ? Doit-on mettre « Livrée » comme règle indispensable dans la Definition of Done de nos demandes ?
Rappel : Faire la Definition of Done des user-story
Il n’y a pas de bonnes réponses en réalité car chaque contexte va vous aider à définir cela. Si ma réponse est logique aux yeux des agilistes, j’ai décidé d’en parler dans un article concret car je me suis aperçu que cette notion de « livraison » dans le Definition of Done était un gros soucis au sein des équipes.
Déploiement continue
Lorsqu’on livre en continue grâce à un processus devops bien huilé, il est très facile de dire que la Definition of Done contient l’obligation de « demande livrée ».
Cependant cela amène un autre aspect encore différent qui est celui de dire, mais est-il encore nécessaire d’avoir une colonne test car en déploiement continu, il n’y a plus de validation humaine avant le déploiement.
Là c’est à voir si vous êtes prêt ou non pour pratiquer ce type de stratégie très difficile à mettre en place. Mais c’est l’idée de ce déploiement continu où le rollback est automatique.
Livraison continue
On est dans le même contexte que le déploiement continue sauf qu’une validation humaine est obligatoire pour déclencher la mise en production. Donc dans ce cas, quand notre Product Owner teste et valide la demande, la mise en production est lancée automatiquement ; il n’aura plus qu’à mettre la demande de « test » à « done » à la fin du déploiement.
Donc à ce niveau là, on considère que le Definition of Done des demandes contient l’obligation de « demande livrée ».
Livraison en fin de sprint
Ce concept qui était très répandu il y a encore peu de temps tend à disparaitre avec toute l’accélération des mises en production qu’on connait avec tous les nouveaux outils mis à disposition des devops.
Quand on fait ce type de stratégie, en général on décide de passer les tickets en « Done » qu’en fin de Sprint lors de la mise en production ; vous comprendrez qu’un Burndown Chart n’est alors pas très utile.
D’ailleurs on amène souvent avec ce type de stratégie de déploiement une période de « freeze » d’une journée (ou 1,5 jours) pour tester et corriger les dernières petites choses pour que la livraison soit top. Dans ce cas, les Product Owner ne testent les choses que dans cette petite période de freeze.
Livraison par release
Cette méthode que je déconseille est encore visible dans les entreprises qui ont une stratégie de livrer des blocs fonctionnels par lot (souvent pour des raisons politiques de l’entreprise).
Ici le « Done » ne contiendra pas la mise en production mais plutôt une mise en recette. Il vous sera impossible de gérer vos projets correctement si vous mettez vos tickets en « Done » qu’au moment de la mise en production qui peut se faire tous les 3 mois.
Le Product Owner testera en recette chaque fonctionnalité mais devra tout retester lors de la préparation de la release générale sur une période de freeze des développements (surtout si il peut avoir plusieurs recettes en parallèle qui augmenterait considérablement les risques de regressions) ; c’est en effet un peu une duplication de travail mais souvent obligatoire pour assurer la qualité fonctionnelle en production.
Je vous recommande fortement de faire votre possible pour éviter cette situation qui est souvent celle qui prend le plus de temps aux équipes.
Récapitulatif des 4 cas
Voici une façon simple de se rappeler des cas présentés :
_______________________________________________________________
Déploiement continue >
« Mise en production » pour être « Done »
Pas de teste humain
_______________________________________________________________
Livraison continue >
« Mise en production » pour être « Done »
Le Product Owner teste en continue puis mise en production
_______________________________________________________________
Livraison fin de sprint >
« Mise en production » pour être « Done »
Le Product Owner teste qu’en fin de sprint
_______________________________________________________________
Livraison par release >
« Mise en recette » pour être « Done » – Mise en production plus tard
Le Product Owner teste en continue en recette
> puis aussi lors de la grosse release en période de freeze
_______________________________________________________________
Conclusion
Vous avez des exemples qui doivent regrouper plus de 99% des cas donc n’hésitez pas à prendre exemple sur eux pour savoir si il est conseillé ou non de mettre la mise en production dans le « Done » de votre Definition of Done.
Si la question se pose, sachez qu’il n’y a pas d’obligation que la definition of Done contienne la mise ne production. Cela dépendra de votre contexte.
1 Rétrolien / Ping