Suggestions sur le cycle de vie des bogues et la gestion des versions

Question

Notre groupe analyse actuellement nos procédures de gestion des versions logicielles formelles et d'intégration avec un bug lifecycle.

Quel modèle de cycle de vie des bogues utilisez-vous? Et pourquoi? Par exemple, supposons que des versions officielles soient générées pour le contrôle qualité une fois par semaine. À quel moment marquez-vous les bogues comme résolus?

• Lorsque le développeur a commis ses modifications?
• Lorsque les modifications ont été examinées et fusionnées dans la branche de publication?
• Lorsque le candidat à la sortie officielle a été créé?

Et quel processus, ou caractéristiques de votre logiciel de suivi de bogues, utilisez-vous pour le suivi?

Y a-t-il des conseils/suggestions/recommandations que vous pouvez partager?

Answer 1

Si vous avez la chance d'avoir un test unitaire qui attrape le bogue, ou si vous êtes capable d'ajouter un nouveau test qui teste spécifiquement le bogue, il offre une bonne mesure objective de la résolution.

Si vous faites des builds continus avec des tests de régression, alors tant que le test correspondant passe sur votre branche primaire, le bug peut être considéré comme résolu. L'avantage de ceci est qu'il est facile de considérer qu'un bogue est résolu sur une branche mais pas sur une autre, ce qui vous amène à tenter l'intégration plus tôt et à mesurer le succès. En fonction de votre culture, vous voudrez peut-être seulement avoir un bug marqué comme réellement résolu s'il réussit les builds automatisés dans toutes les branches.

Un avantage secondaire est que vous pouvez attraper le bogue s'il réapparaît dans le futur, par exemple parce que quelqu'un a annulé quelque chose ou une catastrophe de fusion.