En ce qui concerne la livraison Scrum, les gens s’attendent généralement à une exécution de la version après la fin d’un sprint. Cela signifie directement après une présentation de démonstration réussie au client.
Mais je me suis toujours demandé comment cela pouvait être une attente aussi automatique. Surtout si vous considérez les activités possibles ci-dessous qui doivent avoir lieu avant ou parallèlement.
- Développer et terminer toutes les histoires du sprint. Certaines peuvent être terminées plus tôt, mais la plupart du temps, les histoires sont terminées juste avant la fin du sprint. Peut-être même après la présentation de la démo, à ouvrir ici.
- Effectuez tous les tests planifiés sur le contenu du sprint pour vous assurer que le code à publier est prêt pour la production.
- Rattrapez les bogues découverts et corrigez-les à temps avant la publication.
- Assurez-vous que le pipeline de déploiement est mis à jour avec le contenu le plus récent et que le pipeline lui-même est fiable à exécuter.
- Exécutez le pipeline sur tous les environnements pertinents pour les amener dans le dernier état du code ainsi que du point de vue des données.
- Préparez les notes de version et communiquez avec le client l’impact de la version et ce qui changera exactement par la suite.
- Le cas échéant, synchronisez-vous avec d’autres équipes Scrum parallèles pour vous assurer que le contenu dépendant sera publié simultanément. Rien ne doit manquer pour garantir que le contenu de votre version fonctionnera comme prévu.
- En plus de tout cela, passez par toutes les cérémonies Scrum. Non seulement liés au sprint en cours, mais aussi ceux ciblés pour le prochain sprint (par exemple, les sessions de raffinement des histoires).
Imaginez maintenant que le sprint dure deux semaines.
Les activités de libération en elles-mêmes prennent du temps et des personnes à réaliser. Mais cela ne peut pas prendre trop de temps. Juste après le dernier jour du sprint vient directement le premier jour du sprint suivant, et le cercle recommencera.
L’attente de la libération après chaque sprint semble-t-elle toujours aussi automatique ?
Table des matières
Libérer le traitement du contenu
Si tous les processus du sprint sont automatisés, il est possible de simplement « appuyer sur la gâchette » et d’installer la dernière version du code en production à la fin de chaque sprint. Le problème est que je n’ai jamais connu un état aussi parfait de l’équipe Scrum.
Si c’est effectivement le cas dans certaines petites entreprises privées, je les envie vraiment. Mais la réalité dans le monde de l’entreprise est qu’une équipe Scrum n’atteindra pas ce niveau de maturité. Au contraire, les processus de publication sont généralement liés à des activités chronophages atteignant la plupart du sprint suivant, affectant ce sprint du point de vue du contenu et de toutes les métriques. La libération n’est qu’un acte stressant que personne dans l’équipe n’est heureux de vivre.
J’étais donc après avoir découvert le meilleur scénario suivant pour gérer les versions.
La conclusion était de faire de chaque deuxième sprint le Release Sprint. Voici ce que cela signifie.
Version de code distincte pour la prochaine version
Il s’agit de gérer des branches distinctes dans le référentiel GIT. Il existe de nombreuses façons d’aborder le même problème, et toutes peuvent réussir. Mais pour les besoins de cet article, je vais garder les choses simples pour démontrer l’approche et son impact.
Afin d’avoir un impact aussi faible que possible sur les activités de développement en cours, il est important de séparer le contenu de la prochaine version dans une branche distincte. Appelons-la Release Branch. Avec cela, les problèmes suivants seront résolus :
- L’équipe de développement peut poursuivre ses activités et se fondre dans les nouvelles histoires de 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 de la part de l’équipe Scrum.
- Les activités de test peuvent être exécutées dans un espace isolé. Ici, seuls les changements nécessaires à la résolution des tests 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 un contrôle total sur le contenu à publier. Il ne peut pas arriver qu’un commit inattendu dans la branche Git casse du code déjà testé.
Alors gardez simplement le contenu de la prochaine version de côté et laissez-le se terminer dans un état stable, prêt à être publié.
Chronométrez les sorties pour qu’elles fonctionnent de manière répétée
J’ai abandonné l’ambition de faire la release après que chaque sprint soit terminé. Il était super clair que cela n’aurait aucune chance de fonctionner. Du moins pas avec des effets secondaires tels que :
- impactant le contenu de développement du prochain sprint,
- être incapable de stabiliser le contenu de la version,
- rattraper toutes les activités de test requises, etc.
L’objectif était donc d’exécuter la version à la fin de chaque deuxième sprint. Cela impliquerait ce qui suit :
- Une version contiendra toujours des histoires des deux derniers sprints déjà terminés. Étant donné que la release est effectuée dans le courant (sprint actif), ce contenu de sprint n’est pas encore inclus dans la release.
- Il y a tout un temps d’un sprint pour les activités de test nécessaires et les corrections de bugs à effectuer.
- Le propriétaire de la version a suffisamment de temps pour rassembler les informations pertinentes pour la version (cas de test, notes de version, etc.) avec le sprint de non-version. De cette façon, ils peuvent fonctionner 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 propriétaire de la version peut rapidement se connecter avec le développeur concret pour résoudre le problème et revenir au contenu actuel du sprint. Il devrait donc toujours y avoir un pourcentage de temps alloué à partir de la capacité de l’équipe pour prendre en charge cette correction de bogue. Combien exactement peut être découvert au fil du temps.
Il est clair que les utilisateurs n’obtiendront pas le dernier contenu de sprint dans la dernière version. Mais avec le temps, cela deviendra inutile. Ils recevront de toute façon deux sprints de contenu avec chaque prochaine version, après chaque deuxième sprint.
Cela ressemble à un bon compromis entre la satisfaction d’une livraison rapide et le suivi des activités Scrum sans perturbation significative.
Exécuter le déploiement de la version
Lorsque les activités de test, de correction de bogues et de préparation du pipeline sont terminées avec succès, il est assez simple d’exécuter le pipeline de production et de terminer la mise en production.
Puisqu’il est déployé à partir d’une branche autonome, il peut s’agir d’une activité essentiellement inaperçue et invisible. Personne n’a besoin de savoir. Si tel est le cas, il s’agit de la meilleure implémentation possible du déploiement de la version.
Une condition préalable pour cela est d’avoir créé un solide pipeline DevOps automatisé. Non seulement utilisé pour déployer dans l’environnement de production, mais également dans tous les autres environnements de niveau inférieur. Cela peut inclure le développement, le bac à sable, les tests, l’assurance qualité, l’environnement de performance, etc. Il s’agira d’un simple clic pour déployer toutes les solutions pour chaque environnement.
La libération ne doit pas être un point douloureux ou un stress. Ou un cauchemar que tout le monde craint et continue de se préparer pour ce jour pendant une semaine. Non – au lieu de cela, si personne ne le remarque jamais, c’est le meilleur signe d’une sortie réussie.
Fusionner la branche de publication dans la branche de développement
La branche de publication contient désormais du contenu spécial qui n’existe pas dans la branche de développement en cours régulière. Il est lié à tous les correctifs qui ont été mis en œuvre pendant la période de test. Ce contenu doit être fusionné dans la branche de développement pour garantir que les correctifs y resteront même après la prochaine version.
À 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 peu de temps après le déploiement en production, il peut utiliser cette branche. Il est simple de prendre ce code et d’implémenter le correctif à l’intérieur. Il s’agit toujours de la copie exacte du code de production actuel sans aucun nouveau contenu inédit.
Enfin, une fois que la nouvelle période de test commence, la branche de version précédente peut être supprimée et remplacée par une nouvelle. Le nouveau est à nouveau créé en tant que copie de la branche de développement actuelle.
Établir des versions régulières
Et maintenant nous l’avons 😀—un processus solide pour aborder la sortie. La seule chose qui manque est de s’engager à le garder régulier. Dans ce cas, après chaque deuxième sprint.
En le gardant régulier, nous préparons en fait le terrain pour le rendre plus facile à accomplir, principalement parce que :
- Si la sortie a lieu après une période pas trop longue, il n’y a pas tellement de nouveau contenu à installer en production. L’incrément est faible et considéré comme stable.
- Maintenant, tant de nouveaux contenus signifient qu’il n’y a pas énormément d’activités de test et de création de cas de test. Moins de communications, d’appels d’accord et de collaboration avec les parties prenantes sur ce que tout doit être revalidé. Ils conviendront également qu’il n’y a pas si longtemps depuis la dernière version. On accorde donc moins d’importance à cette action.
- L’équipe s’habituera à ce cycle ; avec le temps, il fera naturellement partie de l’équipe.
- Comme effet secondaire, les environnements de développement et de test sont souvent actualisés. Cela est de toute façon nécessaire pour chaque nouveau cycle de test. Ce ne sera donc pas juste une autre activité planifiée à faire. Plutôt une action qui fait déjà partie du processus établi. Ce changement de perspective a tellement d’influence sur l’ambiance de l’équipe. On ne croirait pas cela.
Conclusion
Ce chapitre conclut mes articles précédents sur le sujet du cycle de vie Scrum. En outre, il s’agit de ce qui s’est avéré fonctionner dans la vraie vie.
Souvent, les équipes commencent de manière agile et font beaucoup de choses de manière erronée. Puis ils évoluent, éventuellement, et commencent à faire les choses différemment. Cette série pourrait aider certains d’entre eux à faire ce changement plus rapidement.
Cette approche de version n’est pas non plus la seule réalisable, ni sans problèmes. Ceux-ci existeront toujours, et les équipes doivent y faire face. Alors améliorez ce qui est possible et oubliez ce qui n’a pas de sens.
Mais d’après ce que je sais, cette approche, bien que simple, a prouvé que le changement est possible. Des sprints chaotiques et imprévisibles à une livraison plus stable avec des versions régulières sur lesquelles on peut compter et avec lesquelles on peut planifier. Et cela ne nécessite pas une méthodologie spéciale très compliquée – juste des règles simples et la volonté de suivre le plan.