Integración continua: ¿cómo relaciona sus compilaciones con requisitos/tareas/errores?

Question

¿Cómo responde las siguientes preguntas de gerentes, probadores y otras personas en su equipo:

¿En qué versión se ha corregido el error # 829? ¿Qué tareas se han completado en nuestra versión de prueba actual?

En pocas palabras, ¿cómo se logra la trazabilidad de sus requisitos, tareas y errores desde el momento en que se reportan los informes hasta la implementación? ¿Qué procesos, herramientas y técnicas estás usando para lograr esto?

Answer 1

Utilizamos TRAC con SVN en nuestra empresa y realizar balanceo diaria construye a DEV/ESTADIFICACIÓN & entornos estables con despliegues regulares programados (una vez al mes ... ish) a un entorno de producción.

Cuando se informa de un error, se entró en TRAC y recibe un número de entradas (por ejemplo, # 1001)

Cuando se fija el fallo, el código se comprueba de nuevo en SVN con el número de ticket (# 1001) en las notas SVN Checkin.

El desarrollador toma nota del número de conjunto de cambios SVN (por ejemplo, [5000]) y abre la interfaz web de TRAC. Al cerrar el ticket, colocan el número del conjunto de cambios en las notas del ticket.

De esta manera, la verificación de SVN hace referencia al ticket ... y el ticket hace referencia a SVN Checkin.

Nuestras compilaciones diarias se realizan luego contra un conjunto de cambios SVN (por ejemplo, la compilación de hoy es todo hasta el conjunto de cambios [5050]) y se incluye una nota en nuestro aviso de implementación.

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

De esa manera los probadores al revisar las correcciones para las pruebas conocen por el conjunto de cambios en los comentarios de las entradas Si la generación que están viendo incluye el arreglo.

Answer 2

Estamos etiquetando el control de origen con el número de defecto que se ha corregido o el número de mejora que se ha implementado.

Al recuperar el registro de registro entre dos compilaciones, puede determinar qué se ha implementado o reparado.

Answer 3

Utilizamos TFS junto con JetBrains 'TeamCity for CI.

Cuando asociamos check-ins con tareas, nuestra política de check-in personalizada antepone las tareas asociadas y los errores con sus ID y títulos a los comentarios de check-in.

Estos comentarios se utilizan para generar las notas de la versión, que se generan automáticamente para cada compilación.

Answer 4

Utilizamos un servicio de SVN administrado llamado Beanstalk (http://www.beanstalkapp.com/) que le permite vincularse fácilmente con una serie de sistemas de administración de errores/funciones. En nuestro caso, usamos FogBugz de Fog Creek para ese fin de cosas. SVN/Beanstalk le permite tomar notas cuando ingresa una compilación que, a su vez, afectará el estado de uno o más casos de FogBugz.

En el extremo del cliente, utilizamos Tortoise SVN y Visual SVN para gestionar la interacción del cliente local y el servidor Beanstalk SVN (Tortoise proporciona el servicio real, Visual SVN proporciona la integración entre Tortoise SVN y MS Visual Studio).

Recomiendo mucho ambos servicios y el cliente Tortoise/Visual SVN.

Answer 5

Estamos utilizando Fogbugz que tiene integración de subversión incorporada. Básicamente, hay un complemento para Fogbugz que comprueba los check-in SVN en segundo plano. Por lo tanto, si proporciona una identificación de Fogbugz-case en su check-in, se vincula automáticamente con este check-in.

Por lo que sé, no necesita ninguna aplicación especial (como Beanstalk, por ejemplo).

El revés es poco complicado. En nuestra compañía existe una convención de que para cada construcción (futura o pasada) hay un "lanzamiento" en Fogbugz. Si soluciona un error o implementa una función, asigne el caso al lanzamiento correcto.

Luego es bastante fácil obtener una lista de todas las características implementadas de la compilación X.