Intégration continue: comment associez-vous vos versions aux exigences / tâches / bugs?

Question

Comment répondez-vous aux questions suivantes des responsables, des testeurs et des autres membres de votre équipe:

Dans quelle version le bogue n ° 829 est-il corrigé? Quelles tâches ont été effectuées dans notre version de test actuelle?

En bref, comment pouvez-vous assurer la traçabilité de vos exigences, tâches et bogues dès leur signalement jusqu'à leur déploiement? Quels processus, outils et techniques utilisez-vous pour y parvenir?

Answer 1

Nous utilisons TRAC avec SVN dans notre société et exécute des constructions glissantes quotidiennes vers DEV / STAGING & amp; Environnements STABLES avec des déploiements réguliers planifiés (une fois par mois, etc.) vers un environnement PRODUCTION.

Lorsqu'un bogue est signalé, il est entré dans TRAC et se voit attribuer un numéro de tickets (par exemple, n ° 1001)

Lorsque le bogue est corrigé, le code est réintégré dans SVN avec le numéro de ticket (# 1001) dans les notes d'enregistrement SVN.

Le développeur prend note du numéro de jeu de modifications SVN (par exemple, [5000]) et ouvre l'interface Web de TRAC. Lors de la fermeture du ticket, ils inscrivent le numéro du changeset dans les notes du ticket.

Ainsi, l'enregistrement SVN référence le ticket ... et le ticket fait référence à l'enregistrement SVN.

Nos versions quotidiennes sont ensuite exécutées sur un ensemble de modifications SVN (par exemple, la version d'aujourd'hui correspond à l'ensemble de modifications [5050]) et une note en est faite dans notre notification de déploiement.

Deployed On   |  Environment            | Changeset
--------------+-------------------------+--------------------------
10-01-2008    |  DEV                    | 5100
10-01-2008    |  STAGING                | 5080
10-01-2008    |  STABLE                 | 5050
01-01-2008    |  PRODUCTION             | 5000

Ainsi, lors de l’examen des correctifs à tester, les testeurs sont informés par les modifications dans les commentaires du ticket si la version étudiée inclut le correctif.

Answer 2

Nous utilisons TFS conjointement avec TeamCity for CI de JetBrains.

Lors de l'association d'associations d'archives à des tâches, notre stratégie d'archivage personnalisée ajoute les commentaires associés aux tâches et aux bogues associés, ainsi que leurs ID et titres, aux commentaires d'archivage.

Ces commentaires sont ensuite utilisés pour générer les notes de publication, qui sont générées automatiquement pour chaque construction.

Answer 3

Nous étiquetons l’enregistrement du contrôle de source avec le numéro de défaut qui a été corrigé ou le numéro d’amélioration mis en œuvre.

En récupérant le journal d’archivage entre deux versions, vous pouvez déterminer ce qui a été mis en œuvre ou corrigé.

Answer 4

Nous utilisons un service SVN géré appelé Beanstalk ( http://www.beanstalkapp.com/ ). cela vous permet de vous connecter facilement à un certain nombre de systèmes de gestion de bogues / fonctionnalités. Dans notre cas, nous utilisons FogBugz de Fog Creek pour cette fin des choses. SVN / Beanstalk vous permet de prendre des notes lorsque vous archivez une version qui affecte à son tour le statut d’un ou plusieurs FogBugz cas.

Du côté du client, nous utilisons Tortoise SVN et Visual SVN pour gérer l’interaction du client local et du serveur Beanstalk SVN (Tortoise fournit le service réel, Visual SVN fournit l’intégration entre Tortoise SVN et MS Visual Studio).

Je recommande vivement les deux services et le client Tortoise / Visual SVN.

Answer 5

Nous utilisons Fogbugz, qui possède une intégration de subversion intégrée. En gros, il existe un plugin pour Fogbugz qui vérifie les archivages SVN en arrière-plan. Donc, si vous fournissez un identifiant de cas Fogbugz lors de votre enregistrement, il sera automatiquement lié à cet enregistrement.

Pour autant que je sache, vous n'avez besoin d'aucune application spéciale (comme Beanstalk par exemple).

L’inverse est un peu délicat. Dans notre entreprise, il existe une convention selon laquelle, pour chaque construction (future ou passée), il existe une "version". à Fogbugz. Si vous corrigez un bogue ou implémentez une fonctionnalité, vous affectez le cas à la version appropriée.

Ensuite, il est assez facile d'obtenir une liste de toutes les fonctionnalités implémentées de la construction X.