Dans le contexte de la livraison Scrum, l’attente commune est une publication de version immédiatement après la conclusion d’un sprint. Ceci est souvent perçu comme survenant directement après une présentation de démonstration réussie au client.
Cependant, il est pertinent de questionner la pertinence d’une telle attente automatique, surtout au regard des activités suivantes qui doivent être menées avant ou en parallèle de la publication :
- Le développement et la finalisation de toutes les histoires du sprint. Bien que certaines puissent être achevées plus tôt, la majorité sont souvent terminées juste avant la fin du sprint, voire même après la présentation de la démonstration.
- L’exécution exhaustive de tous les tests planifiés sur le contenu du sprint, afin de s’assurer que le code prêt à être publié est adéquat pour la production.
- L’identification et la correction des bogues détectés dans les délais impartis avant la publication.
- La vérification de la mise à jour du pipeline de déploiement avec le contenu le plus récent, et de la fiabilité du pipeline lui-même.
- L’exécution du pipeline sur tous les environnements pertinents pour assurer que le code et les données soient à jour.
- La préparation des notes de version et la communication avec le client concernant l’impact de la publication et les changements précis qui en découleront.
- La synchronisation avec d’autres équipes Scrum en parallèle, le cas échéant, pour garantir que tout contenu dépendant soit publié simultanément. Il est impératif de ne rien omettre pour assurer le bon fonctionnement de la version.
- La participation à toutes les cérémonies Scrum, non seulement celles liées au sprint en cours, mais aussi celles planifiées pour le prochain sprint, comme les séances de raffinement des histoires.
Prenons l’exemple d’un sprint d’une durée de deux semaines.
Les activités de publication demandent du temps et des ressources humaines. Toutefois, elles ne peuvent pas s’étendre indéfiniment, car le dernier jour d’un sprint est immédiatement suivi du premier jour du sprint suivant, et le cycle recommence.
Dans ce contexte, l’attente d’une publication après chaque sprint semble-t-elle toujours aussi naturelle ?
Gestion du contenu de la publication
Si tous les processus du sprint sont automatisés, il serait envisageable d’« appuyer sur un bouton » pour déployer la dernière version du code en production à la fin de chaque sprint. Néanmoins, cette situation idéale est rarement atteinte dans les équipes Scrum.
Bien que certaines petites entreprises privées puissent y parvenir, la réalité du monde de l’entreprise est que les équipes Scrum peinent à atteindre ce niveau de maturité. Les processus de publication impliquent souvent des activités chronophages qui débordent sur le sprint suivant, affectant ainsi le contenu et les indicateurs du sprint en question. La publication devient alors une source de stress que personne dans l’équipe ne souhaite vivre.
C’est pourquoi il est crucial de rechercher un scénario optimisé pour la gestion des publications.
La solution proposée est de désigner un sprint sur deux comme « Sprint de Publication ». Voici ce que cela implique.
Branche de code distincte pour la prochaine version
L’idée est de gérer des branches distinctes dans le référentiel GIT. De nombreuses approches sont possibles, et chacune peut s’avérer efficace. Pour les besoins de cet article, nous simplifierons les choses pour illustrer l’approche et son impact.
Afin de minimiser l’impact sur les activités de développement en cours, il est essentiel de séparer le contenu de la prochaine version dans une branche dédiée, que nous appellerons « Branche de Publication ». Cette approche permet de résoudre les problèmes suivants :
- L’équipe de développement peut poursuivre ses activités et intégrer de nouvelles histoires dans la branche principale sans interruption.
- Il n’y a aucun risque que le contenu de la version soit affecté par des modifications de code inattendues provenant de l’équipe Scrum.
- Les activités de test peuvent être réalisées dans un environnement isolé, où seuls les changements nécessaires à la résolution des problèmes détectés seront introduits.
- Étant donné que le pipeline de publication ne déploiera en production que le contenu de la branche de publication, nous avons un processus clair et une maîtrise totale sur le contenu à publier. Ainsi, un commit inattendu dans la branche Git ne risque pas de compromettre du code déjà testé.
Il convient donc de conserver le contenu de la prochaine version à part, afin qu’il atteigne un état stable et soit prêt à être publié.
Planifier les publications pour qu’elles fonctionnent de manière récurrente
L’objectif de publier après chaque sprint a été abandonné. Il est apparu clairement que cette approche ne pouvait fonctionner sans engendrer d’effets secondaires négatifs tels que :
- l’impact sur le contenu de développement du sprint suivant
- l’incapacité à stabiliser le contenu de la version
- l’incapacité à mener à bien toutes les activités de test requises
L’objectif est donc de réaliser la publication à la fin de chaque deuxième sprint, ce qui implique:
- Une version contiendra toujours les histoires des deux derniers sprints terminés. Étant donné que la publication est effectuée pendant le sprint actif, le contenu de ce sprint n’est pas encore intégré à la version.
- Un sprint complet est alloué aux activités de test et de correction de bogues.
- Le responsable de la version a suffisamment de temps pour rassembler les informations pertinentes (cas de test, notes de version, etc.) pendant le sprint sans version. Il peut ainsi travailler de manière autonome et laisser le reste de l’équipe de développement travailler sur de nouvelles histoires.
- En cas de découverte de bogue, le responsable de la version peut rapidement contacter le développeur concerné pour résoudre le problème et retourner au contenu du sprint en cours. Un pourcentage de temps doit être alloué pour permettre la prise en charge de ces correctifs. La quantité exacte peut être déterminée au fil du temps.
Bien que les utilisateurs ne reçoivent pas le dernier contenu du sprint dans la dernière version, avec le temps, cela perdra de son importance. Ils recevront deux sprints de contenu à chaque publication, après chaque deuxième sprint.
Cela représente un compromis avantageux entre la satisfaction d’une livraison rapide et le respect des activités Scrum sans perturbation notable.
Exécuter le déploiement de la version
Une fois que les activités de test, de correction de bogues et de préparation du pipeline sont achevées avec succès, il est simple de lancer le pipeline de production et de finaliser la mise en production.
Étant donné que le déploiement est effectué à partir d’une branche autonome, il peut s’agir d’une activité relativement discrète et invisible. Si tel est le cas, il s’agit de l’implémentation la plus aboutie du déploiement de la version.
Il est primordial d’avoir un pipeline DevOps automatisé robuste, non seulement pour le déploiement dans l’environnement de production, mais également dans tous les autres environnements de niveau inférieur tels que le développement, le bac à sable, les tests, l’assurance qualité, l’environnement de performance, etc. Il suffira d’un simple clic pour déployer toutes les solutions dans chaque environnement.
La publication ne doit pas être un processus douloureux, stressant ou un cauchemar que tout le monde redoute pendant une semaine. Au contraire, si elle passe inaperçue, c’est le signe d’une publication réussie.
Fusionner la branche de publication dans la branche de développement
La branche de publication contient du contenu spécifique qui n’est pas présent dans la branche de développement courante, notamment tous les correctifs mis en œuvre pendant la période de test. Ce contenu doit être fusionné dans la branche de développement pour assurer que les correctifs soient conservés même après la prochaine publication.
À ce stade, la dernière version de la branche sert de code de production d’urgence prêt à être redéployé. Si un problème urgent de haute priorité doit être résolu rapidement après le déploiement en production, cette branche peut être utilisée. Il est simple de reprendre ce code et d’y implémenter le correctif. Il s’agit toujours de la copie exacte du code de production actuel sans aucun nouveau contenu inédit.
Enfin, lorsque la nouvelle période de test commence, la branche de publication précédente peut être supprimée et remplacée par une nouvelle, créée à partir d’une copie de la branche de développement actuelle.
Établir des publications régulières
Nous voici donc avec un processus solide pour gérer les publications. Il ne reste plus qu’à s’engager à le maintenir régulier, c’est-à-dire après chaque deuxième sprint.
En maintenant une régularité, nous facilitons grandement le processus, notamment parce que :
- Si la publication a lieu après une période raisonnablement courte, il n’y a pas une quantité excessive de nouveau contenu à installer en production. L’incrément est faible et considéré comme stable.
- Moins de nouveau contenu implique moins d’activités de test et de création de cas de test. Moins de communication, de réunions de coordination et de collaboration avec les parties prenantes pour valider les éléments. Ces dernières seront d’accord que la dernière version n’est pas si lointaine. Une importance moindre est donc accordée à cette action.
- L’équipe s’habituera à ce cycle et, avec le temps, il deviendra une partie intégrante de son fonctionnement.
- Un effet secondaire est que les environnements de développement et de test sont souvent mis à jour, ce qui est de toute façon nécessaire pour chaque nouveau cycle de test. Ce ne sera donc pas une activité supplémentaire à planifier, mais une partie intégrante du processus établi. Ce changement de perspective a un impact notable sur l’ambiance de l’équipe.
Conclusion
Ce chapitre conclut mes articles précédents sur le cycle de vie Scrum, en présentant ce qui s’est avéré fonctionner en pratique.
Les équipes débutent souvent avec l’agilité en commettant des erreurs. Elles évoluent par la suite et adoptent de nouvelles pratiques. Cette série d’articles vise à aider certaines d’entre elles à accélérer ce changement.
Cette approche de publication n’est pas la seule envisageable, ni sans défauts. Il y aura toujours des défis à relever. Il est donc primordial d’améliorer ce qui est possible et d’abandonner ce qui n’a pas de sens.
Cependant, cette approche, bien que simple, a démontré qu’il est possible de passer de sprints chaotiques et imprévisibles à une livraison plus stable avec des versions régulières et fiables. Cela ne nécessite pas une méthodologie complexe, mais simplement des règles claires et la volonté de suivre le plan.