Comment générer des notes de mise à jour ?

Question

[Question]
Est-ce que quelqu'un produit des notes de version via un processus automatisé ? Si oui, comment. En particulier avec des services d'intégration continue. Utilisez-vous simplement un script pour analyser les fichiers journaux des problèmes corrigés pour cette version afin de créer le fichier texte approprié ?

[Contexte]
Récemment, j'ai mis en place l'intégration continue pour mes projets de loisirs. Dans le cadre de cette intégration, j'ai intégré des rapports de suivi des problèmes dans mes constructions. Cependant, pour les versions, je souhaite faire la même chose et obtenir un fichier de notes de version similaire au fichier nhibernate release notes.txt que je trouve très propre.

[Exemple]

Version 1.2.1

Correction d'un bug :

* [ID-1] - The system doesn't accept valid usernames

Améliorations :

* [ID-2] - Saving the file takes 3 minutes when it should take a few seconds. 

Nouvelles fonctionnalités :

* [ID-3] - Allow users to refresh the page using the F5 key.

Tâche accomplie :

* [ID-4] - Document undocumented configuration properties.

Answer 1

En général, ce genre de choses est effectué par un logiciel de suivi des problèmes. Vous suivez chaque nouvelle fonctionnalité, chaque correction de bogue et chaque amélioration, vous les affectez à une version et vous générez ensuite des notes de version à partir des descriptions.

Answer 2

Si vous utilisez maven, il existe une fonction plugin maven changes à cette fin et la production de ce rapport pourrait donc être facilement automatisée dans le cadre d'un processus d'intégration continue.

Answer 3

Si vous utilisez JIRA (que je suggère de toute façon), il peut générer automatiquement les notes de mise à jour pour vous . Le format intégré est plutôt simpliste, mais fonctionne bien dans de nombreux cas. Le contenu est personnalisable jusqu'à un certain point, bien qu'il ne s'agisse pas du nec plus ultra en termes de flexibilité.

Si vous souhaitez obtenir de meilleures notes de version de JIRA, essayez l'option Plugin de visualisation des PDF . Il :

• plus qu'une simple liste de "problèmes résolus" (par exemple : instructions d'installation et de mise à niveau, détails juridiques, tests exécutés, fichiers modifiés)
• plus de contrôle sur ce qui est inclus (exclusion de certains statuts, résolutions, types de problèmes, etc.)
• permet de distribuer votre document de notes de mise à jour par courrier électronique (format PDF) ou de l'imprimer sur papier

Clause de non-responsabilité : je suis un développeur de ce complément commercial de JIRA.

Answer 4

Je suis confronté aux mêmes problèmes. Dans notre développement, nous utilisons svn/jira et nous avons un outil personnalisé qui tentera de construire et de tester les changements avant qu'ils ne soient validés - et le développeur entre le numéro jira dans le cadre de ce processus (il valide le numéro). Ce numéro jira est ensuite inclus dans le commit SVN.

A partir de là, nous générons une note de publication entre deux points de svn et, à partir des commentaires sur chaque livraison, nous pouvons établir une liste des problèmes qui ont été livrés et alimenter la note de publication.

Le problème, c'est que 1. les questions figurant dans la note de mise à jour doivent être introduites en tant que modifications du code. Les problèmes corrigés sans changement de code ne sont pas inclus. 2. Si un développeur est à mi-chemin d'une correction, celle-ci apparaîtra dans les notes de publication alors qu'elle ne devrait pas y figurer.

Je souhaite trouver une solution avec un minimum de travail manuel qui nous permette de prendre n'importe quelle version de notre système de CI et de la transformer en version.

J'envisage d'adapter le processus de manière à ce que la génération d'une note de publication échoue si un problème n'est pas résolu - mais je pense que les développeurs se plaindront d'être à mi-chemin d'un problème lorsque nous voudrons faire une publication.

L'autre option consiste à n'inclure dans la note de mise à jour que les problèmes résolus. Cependant, le problème est que si un développeur a apporté une correction dans la version A mais n'a pas clôturé le problème au moment de la publication de la version A, puis n'a pas modifié le code et a clôturé le problème après la publication de la version A, comment puis-je inclure automatiquement ce problème dans les notes de publication (je pourrais peut-être rechercher tous les problèmes clôturés entre la version A et la version B....) ?

Merci de votre lecture

Answer 5

Dans mon entreprise, nous utilisons bugzilla. Nous utilisons le jalon pour marquer un bogue avec un numéro de version spécifique. Ensuite, nous générons un rapport xml pour tous les bogues avec un jalon spécifique et nous utilisons un petit script pour générer les notes de mise à jour à partir de ce rapport.

Ceci peut être facilement généralisé à tout logiciel de suivi des bogues, en général.

Je suppose qu'il pourrait également être lié aux commentaires dans les messages de validation de votre système de contrôle de version. Une requête pourrait être faite pour lister tous les commentaires sur les livraisons sur le système de contrôle de version et ensuite filtrer tous les commentaires avec un tag spécifique.