Gestión de Bugs y otras cuestiones
Como usar Scarab
Creación: 30-06-2006
Índice de contenidos
1. Introducción
En Autentia (http://www.autentia.com) siempre defendemos la correcta gestión de la información en general, y en particular de la información referente al desarrollo de software. Por eso en este tutorial vamos a hablar de Scarab (http://scarab.tigris.org/)
un software que nos va a permitir gestionar toda la información referente a los bugs, modificaciones, mejoras, nuevas funcionalidades, y en general “cambios”, que hagamos
sobre un desarrollo.
Scarab es un producto open source de Tigris (http://www.tigris.org/).
Al igual que podemos decir que la comunidad Apache (http://www.apache.org/) es un
referente para el desarrollo open source basado en Java. La comunidad Tigris lo es para las herramientas open source de colaboración y desarrollo de software. Entre ellas podemos recomendar ArgoUML (http://argouml.tigris.org/) para el modelado de sistemas con UML, o Subversión (http://subversion.tigris.org/) como repositorio de código. Pero en general vamos a encontrar herramientas de mucha calidad dentro de esta comunidad (por eso hoy
vamos a hablar de Scarab 😉
2. Entorno
El tutorial está escrito usando el siguiente entorno:
- Hardware: Portátil Ahtec Signal 259M MXM (Sonoma 2.1 GHz, 2048 MB RAM, 100 GB HD).
- Sistema Operativo: GNU / Linux, Debian Sid (unstable), Kernel 2.6.16, KDE 3.5
- Máquina Virtual Java: JDK 1.5.0_07 de Sun Microsystems
- Tomcat 5.5.17
- Eclipse 3.1.2
- Scarab 1.0 beta 20
3. Creación de un módulo
Lo primero que vamos a hacer es dar de alta un módulo. Podríamos comparar el módulo con un proyecto, aunque la idea de módulo es más amplia y más genérica.
Cada módulo tendrá sus propios usuarios, roles, e issues (se hace referencia a “issue” para referirse a un error, una mejora, una nueva funcionalidad, …)
Para crear el módulo, estando logados como el administrador, pinchamos sobre la opción “Modules” del menú de la izquierda. Entramos en la siguiente pantalla:
Sobre esta pantalla pinchamos sobre el botón “Create new”, y rellenamos los datos del módulo en la siguiente pantalla (los campos marcados con un asterisco son obligatorios):
Pulsamos el botón “Create” y ya tenemos un nuevo módulo.
4. Añadir usuarios
Ahora vamos a crear un usuario. Es tan sencillo como antes, pulsamos sobre “Users” del menú de la izquierda, y luego sobre “Add new user”. Obtenemos la siguiente pantalla donde introducimos los detalles del nuevo usuario:
Una vez rellenos los campos, pulsamos sobre el botón “Add”.
Nota: Es conveniente comentar que la clave que le asignemos al usuario es temporal, ya que la primera vez el usuario se autentique en el sistema, este le obligará a cambiarla.
Ahora sería conveniente asignar los roles del usuario en los distintos módulos. Para ello pulsamos sobre “User management” del menú de la izquierda. Nos aparece una pantalla de búsqueda sobre la que pulsamos el botón “Search” (si lo deseamos podemos rellenar alguno de los criterios de búsqueda).
En la lista de resultado seleccionamos (con el radio button de la izquierda del nombre) el usuario para el que vamos a modificar sus roles, y pulsamos el botón “Edit roles”.
Nos aparece la siguiente pantalla sobre la que podemos elegir los roles para el usuario.
Evidentemente cada rol tiene asociados unos permisos. Si queremos comprobar los permisos asociados a cada rol lo podemos hacer pinchando en “Roles” del menú de la izquierda.
5. Añadir Issues
Ahora que ya tenemos creado un módulo y un usuario estamos en disposición de añadir nuevos issues.
Para ello lo primero que vamos a hacer es logarnos en Scarab con el nuevo usuario (ya sabéis que en general hay que intentar usar las cuentas de administración lo menos posible).
Una vez autenticados como un usuario “normal”, vemos que la pantalla inicial nos presenta opciones para crear distintos tipos de issue:
Estos serían los tipos de issue por defecto en Scarab pero, por supuesto, lo podemos cambiar desde el menú del administrador: “Admin –> Global data –> Global issue types” para afectar a todos los módulos, o desde “Admin –> Modules –> Manage issue types” para afectar a un módulo concreto.
Vamos a comentar estos 5 tipos de issue:
- Defect: damos de alta un defecto, un bug, un error, una pifia, … es decir, es algo que ya existe en la aplicación pero que está funcionando mal.
- Patch: es un tipo un poco confuso, se podría entender como que damos de alta la construcción de un parche para la aplicación, un parche podría contener a su vez distintos defectos. Se entiende un parche como una modificación puntual sobre la aplicación, que sólo corrige errores.
- Task: es un tipo un poco confuso, se podría entender como un contenedro de otros issues para hacer algo como sacara una nueva release. Al contrario que en un path, en una task podríamos incluir errores, mejoras y nuevas funcionalidades.
- Feature: damos de alta una nueva funcionalidad a implementar en al aplicación. Se trata de algo que la aplicación todavía no sabe hacer.
- Enhancement: damos de alta una mejora. Se entiende como una mejora algo que ya existe en al aplicación y esta funcionando correctamente, pero que se quiere ampliar su funcionalidad, o hacer alguna mejora al respecto (por ejemplo una mejora de rendimiento).
Se podría decir que cualquier issue se puede expresar como un defect (defecto), feature (funcionalidad) o enhancemente (mejora). Los otros dos (patch y task) podríamos hasta quitarlos sin mucho problema. En cualquier caso recordar que es configurable y lo podéis adaptar según vuestras necesidades.
5.1. Añadir un defecto
Pinchamos sobre “Defect” y pasamos a la siguiente pantalla donde podemos dar de alta el defecto.
Pulsamos sobre el botón “Next” y pasamos a una pantalla donde podemos introducir los detalles del defecto:
En esta pantalla podemos poner datos como la descripción, si está confirmado o no, si ya está corregido, la prioridad, …
En esta pantalla también se pueden adjuntar ficheros.
Al final de la pantalla ponemos la razón del cambio de estado del issue (en este caso la creación), y a que estado pasa el issue. Por defecto, después de la creación viene la asignación (es decir, alguien tiene que hacerse cargo del issue).
Estos pasos (cambios de estado de un issue) vienen definidos por el workflow. Scarab está pensado para podre “enchufarle” distintos workflows. Por defecto (a partir de la versión milestone 20) viene un workflow denominado “BasicWorkflow”, el cual podríamos decir que es la mínima expresión de un workflow.
6. Conclusiones
Vemos que Scarab es altamente configurable y extensible. Sobre todo muy interesante la opción de definir nuestros propios workflows para los issues).
Lo que hemos visto en este tutorial no es mas que una ínfima parte de todo el potencial que nos ofrece Scarab. Os dejamos como para que sigáis explorando sus opciones, y haciendo tutoriales para compartir con todos nosotros aquello que os resulte interesante.
Lo que está claro es que ahora podemos hacer la correcta gestión de cambios (erres, mejoras, nuevas funcionalidades, …) de nuestras aplicacións.
Desde Autentia (http://www.autentia.com) os recomendamos el uso de este tipo de herramientas para conseguir un correcto control de los proyectos.
7. Sobre el autor
Alejandro Pérez García, Ingeniero en Informática (especialidad de Ingeniería del Software)
Socio fundador de Autentia (Formación, Consultoría, Desarrollo de sistemas transaccionales)
mailto:alejandropg@autentia.com
Autentia Real Business Solutions S.L. – “Soporte a Desarrollo”
