Versioning sémantique dans Agile

Disons que j'ai 14 jours d'itérations de sprint où j'ai plusieurs histoires de nouvelles fonctionnalités, quelques améliorations et quelques bugs à corriger. Je déploie également ces changements lorsqu'ils sont prêts, je n'attends pas la fin du sprint.

Mon problème est - comment suivre le versioning sémantique des produits développés et maintenus comme ça? S'il y aura une sortie tous les 14 jours, ce sera facile, je vais augmenter le numéro de version et noter toutes les modifications dans le journal des modifications. Mais que se passe-t-il si les changements sont déployés en continu? Faut-il augmenter la version à chaque fois que quelque chose est déployé? Ou devrais-je attendre la fin du sprint et après cela, faire un "résumé" et augmenter le numéro de version une seule fois par itération indépendamment lors du déploiement réel? Quelles sont les meilleures pratiques pour le versioning sémantique dans Agile?

EDIT: Pour mieux expliquer mes besoins, je veux en premier lieu un changelog pour les parties prenantes. Je ne pense pas qu'ils seront intéressés par un nouvel enregistrement dans le journal des modifications après chaque changement déployé.

Pour la gestion des versions standard, vous souhaiterez qu'un numéro de build soit généré par votre système de build afin que les DLL soient versionnées à chaque fois qu'elles sont déployées. Cela vous permettra de vérifier ultérieurement la version déployée sur un serveur donné.

Votre version «marketing», qui est généralement insérée dans les notes de publication ou publiée sur votre site, ne doit pas être mise à jour à chaque version. Ces notes de version doivent être accumulées et regroupées, probablement synchronisées avec la fin de votre sprint.

Si le schéma de gestion de versions sémantique classique "MAJOR.MINOR.PATCH" a du sens, cela dépend de qui vous déployez, et surtout quand et à quelle fréquence vous le déployez vers l'utilisateur final . Le schéma est très utile si vous travaillez avec la version stable "4.5", où vous commencez par la version 4.5.0. Les versions 4.5.1, 4.5.2, etc. ne contiennent que des correctifs de bogues, tandis que vous travaillez déjà en interne sur la version 4.6.

Par exemple, si vous fournissez une "branche stable" à votre utilisateur final, donnez-lui une version 4.5.0 pour le déploiement initial et 4.5.1, 4.5.2 chaque fois que vous publiez un correctif. Dans votre développement interne "agile" et votre déploiement mid-sprint, vous pouvez déjà avoir une version 4.6, il suffit de l'appeler une "version beta". Chaque fois que vous le déployez au milieu du sprint, ajoutez le numéro de build généré automatiquement comme "4.6.beta build 123". Lorsque votre sprint se termine, affectez-lui "4.6.0" et changez le numéro de version du prochain sprint en interne sur "4.7". Commencer par ".0" n'est qu'une convention, vous pouvez également utiliser le ".0" pour baliser les versions bêta, et commencer par ".1" pour vos utilisateurs finaux. À mon humble avis, le mot «bêta» est beaucoup plus expressif, disant à tout le monde que le sprint «n'est pas encore terminé».

Si vous publiez un journal des modifications complet pour l'utilisateur final, chaque version bêta dépend de vous, mais au moins à la fin du sprint, le journal des modifications doit être terminé et chaque fois que vous fournissez un correctif de bogue à l'utilisateur final, vous devez également mettre à jour les documents d'histoire.

Vous trouverez la stratégie de libération de deux branches séparées, une branche "stable" avec des numéros de version sémantiques et une "branche de développement" marquée avec des numéros de build ou quelque chose de similaire, dans de nombreux produits open source comme Inkscape, Firefox ou 7-zip.

Cependant, si vous ne travaillez pas avec des branches stables et de développement distinctes et que vous publiez quotidiennement une nouvelle version pour vous, vous devez également incrémenter un numéro de version quotidiennement. Dans un tel cas, les numéros de version "4.5.1", "4.5.2", ... refléteront probablement vos déploiements individuels et n'indiqueront pas la différence entre les corrections de bogues et d'autres modifications. Cela peut être correct, ce n'est tout simplement plus du "versionnage sémantique" classique. Dans ce scénario, vous pouvez également déployer les versions 4.5, 4.6, 4.7, 4.8, ce qui ne fait aucune différence réelle.

Concernant votre question sur les entrées dans votre changelog: IMHO quand quelque chose est visible pour l'utilisateur final, cela vaut une entrée dans le changelog, dès que vous déployez le changement. Par exemple, si vous utilisez des bascules de fonction et apportez des modifications à une fonction semi-intégrée qui n'est pas encore activée pour l'utilisateur, qui n'appartient pas à un journal des modifications. Si vous effectuez uniquement une refactorisation, sans modification visible de l'utilisateur, cela n'appartient pas à un journal des modifications. Si vous corrigez un bogue qui aurait pu affecter certains utilisateurs, cela appartient définitivement au journal des modifications - et il devrait y être mentionné en même temps lorsque vous déployez le correctif. Et peu importe si vous publiez quotidiennement ou mensuellement ou annuellement.

J'utiliserais des numéros de build. Habituellement, un numéro de build correspond à la version la plus élevée du système de contrôle de version. Si le numéro de build du lundi était 1745 et qu'il y a eu 5 changements dans le mardi, le numéro de build du mardi soir serait 1750.

Faites ensuite un bref résumé de ce qui a changé entre 1745 et 1750.

Ensuite, chaque fois que vous mettez à jour le numéro de version de votre système, vous pouvez additionner tous les courts résumés des versions pour obtenir les modifications du dernier numéro de version à la nouvelle.

Ma méthode préférée que j'utilise depuis au moins quelques années maintenant est d'augmenter le nombre après la fin de chaque histoire. Cela signifie que les versions publiées à la fin du sprint ne seront pas continues, par exemple, après 1.2.3, vous pourriez trouver 1.5.2 plutôt que 1.4.0.

Dans le journal des modifications, vous pouvez soit répertorier les versions intermédiaires avec leurs descriptions correspondantes, soit simplement regrouper toutes les modifications dans la version "publiée" et ignorer les versions intermédiaires.

Au départ, j'avais peur que les utilisateurs trouvent les "trous" entre les numéros de version problématiques, mais une fois qu'ils le savent, ce n'est pas un problème dans la pratique. Le grand avantage est que l'augmentation du nombre après chaque histoire rend le processus moins sujet aux erreurs - vous n'avez pas à vérifier l'ensemble du travail à partir de 2 semaines pour décider quel sera le prochain numéro de version - lorsque vous regardez une seule histoire, il est évident . De plus, les «sauts» de numéros de version entre chaque version donnent une estimation approximative du nombre de modifications apportées à la version. Dans l'ensemble, j'ai trouvé que ce système fonctionnait bien (c'était avec les clients internes à l'entreprise, mais si vous travaillez déjà dans un cycle de version agile, il devrait également fonctionner pour les clients externes).