Integración con sistemas de Bug Tracking desde NetBeans 6.7.
0. Índice de contenidos.
- 1. Introducción.
- 2. Entorno.
- 3. Configuración.
- 4. Consulta de bugs.
- 5. Creación de bugs.
- 6. Integración con el sistema de control de versiones.
- 7. Conclusiones.
1. Introducción.
En este tutorial vamos a examinar el soporte que proporciona NetBeans para la integración con sistemas de Bug Tracking.
Un sistema de Bug Tracking es una herramienta de seguimiento de errores y del ciclo de desarrollo de software, que nos da soporte en sus distintas fases,
especialmente en las de desarrollo, pruebas y mantenimiento. El objetivo es el de mantener documentadas todas las historias en la fase de desarrollo y todos los bugs
en la fase de mantenimiento, conocer qué miembro del equipo está asignado a la resolución de los mismos, el nivel de prioridad respecto al resto para su implementación o resolución,
en qué versión fue solucionado un bug…
Existen muchos sistemas de Bug Tracking, entre los más conocidos:
Altassian Jira (comercial, LGPL para proyectos open source),
Mantis (GPL),
Bugtrack (comercial),
Bugzilla (LGPL),…
Desde la versión 6.7, NetBeans incluye soporte a la integración con sistemas de Bug Tracking, al estilo del plugin Mylyn para Eclipse y,
por defecto, proporciona soporte para Bugzilla.
2. Entorno.
El tutorial está escrito usando el siguiente entorno:
- Hardware: Portátil Asus G1 (Core 2 Duo a 2.1 GHz, 2048 MB RAM, 120 GB HD).
- Sistema operativo: Windows Vista Ultimate.
- JDK 1.6.0_14
- NetBeans 6.7.1.
3. Configuración.
En la pestaña «Services», o «Prestaciones» si lo tenéis en castellano ;), podemos encontrar la nueva opción «Issue Trackers».
Para crear un nuevo Issue Tracker basta con «botón derecho» sobre esta opción y, al seleccionar «Create Issue Tracker», se mostrará una ventana como la que sigue:
Podemos validar la información realizando un «ping» con el botón «Validate», si no puede conectar o el usuario no es correcto informa de ello, si bien, un error en la contraseña no lo valida.
Una vez configurado disponemos de un nuevo nodo bajo la opción de «Issue Trackers»:
4. Consulta de bugs.
Sobre el nodo tenemos las siguientes opciones, una de ellas la de consulta de bugs:
Al pulsar se mostrará una ventana como la que sigue:
Desde la que podremos realizar las mismas búsquedas que se pueden llevar a cabo desde la consulta avanzada del propio Bugzilla sin necesidad de acceder a la interfaz web del mismo.
5. Creación de bugs.
Accediendo ahora a la opción «Report an Issue»:
Se mostrará una ventana como la que sigue
Desde la que podremos dar de alta un bug asociado a nuestro proyecto.
6. Integración con el sistema de control de versiones.
La integración más interesante es la de acceder al bug sobre el que estamos trabajando directamente desde la ventana de documentación del commit en el sistema de control de versiones.
Lo ideal es mantener sincronizada la información del sistema de Bug Tracking con la del control de versiones, de modo que toda subida al repositorio haga referencia al número de bug o issue
con la que se corresponde y que en el bug correspondiente se haga referencia al número de revisión en el que se subieron los fuentes. De este modo los cambios son trazables desde ambos puntos.
Desde la ventana de commit tenemos disponible una opción en la parte inferior que nos permite realizar una búsqueda del bug al que vamos a asociar la subida de código al repositorio o crear uno nuevo para asociarlo:
Además permite:
- marcar el bug en Bugzilla como resuelto,
- añadir un comentario automáticamente en el Bugzilla con el comentario del commit y el número de revisión de la subida,
- añadir información adicional al comentario superior con información sobre el número y descripción del bug,
Adios a los olvidos a la hora de documentar los cambios en el Bugzilla!
Una vez realizado el commit si buscamos el bug aparecerá entre los solucionados con un comentario como el que sigue:
Y si revisamos el histórico de cambios del fichero que hemos subido se mostrará como sigue:
7. Conclusiones.
Es esencial que los cambios queden relacionados en el control de versiones con el bug que tiene la documentación del mismo. Si además mantenemos la dinámica de incluir en el
bug el número de revisión será más fácil volver atrás e identificar un cambio, sobre todo, cuando las cosas no van del todo bien.
Este tipo de integraciones, más que ser interesantes, su uso debería ser de obligado cumplimiento.
Un saludo.
Jose
