Re: [mindfood] Dudas sobre herramientas para el control de proyecto

[Jose San Leandro <jose.sanleandro@xxxxxxxxxxxx>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wednesday 26 May 2004 21:07, Ibanez, Diego wrote:
> Hola,
>
> estoy intentando montar el entorno de trabajo para el proyecto con el que
> me toca lidiar este veranito. Las principales dudas las tengo en la
> herramienta para hacer los builds y en el cambio del sistema de control de
> versiones.
>
> Respecto a la herramienta para lanzar builds y tests unitarios en la
> actualidad trabajamos con ant y un unico build.xml en el que tenemos
> definido todo. Parece que con maven me puede aportar mas cosas, pero
> alguien me las podria resumir para terminar de convencerme? Por lo que
> entiendo Maven no permite planificar builds y detectar cambios en el
> control de versiones, necesitaria para esta tarea AntHill o CruiseControl?

En lo que parece interesarte, Maven no ofrece ventajas apreciables. Es decir, 
Maven compilará y probará tu proyecto de igual forma que tu build.xml.Además, 
te generará informes con los resultados, y ejecutará las herramientas de 
auditoría de código que elijas.

> Nosotros para los builds automaticos habiamos trabajado con CruiseControl
> que funcionaba bien aunque nos llevo su tiempo montarlo, pero estaba un
> poco verde y en 2 dias estabamos contribuyendo, lo cual no dice mucho de la
> herramienta.

Bueno, lo que dice de la herramienta es que existe, la has probado, y has 
decidido que no te compensa, y lo más importante, te ha permitido elegir cómo 
realizar esa inversión: económica (soporte, formación, etc) o dedicando tu 
propio tiempo. Pero dejemos eso a un lado :).

> El control de versiones lo hacemos con ClearCase lo cual para trabajar en
> servidor es muy bonito pero que es un poco pesadilla para trabajar de
> manera distribuida, por lo que estaba pensando en CVS aunque tengo
> entendido que Subversion lo mejora. Teneis experiencia con Subversion?

En principio Subversion añade a CVS algunas funcionalidades: commits atómicos, 
metadatos, operaciones sobre directorios, branches más livianos, etc. Sin 
embargo, no dispondrá de un GUI comparable a los que existen para cvs.
Para lo que tú necesitas ahora mismo, seguramente saques provecho de las 
mejoras de Subversion sólo después de disponer de un conjunto de herramientas 
que domines y que satisfagan tus necesidades.

> Bueno si alguien cree haber dado con una combinación que le funcione que me
> lo comente.

Mi recomendación es que definas tu metodología. Qué se hace y cuándo. Cómo 
afecta un bug a las releases de tu proyecto. A algunos les vale con las 
notificaciones de CVS, otros utilizamos además un repositorio de bugs y de 
dependencias.
El modelo que yo vengo usando está formado por CVS, Bugzilla y Maven. Puede 
decirse que "me funciona" en el sentido de que es un método que "fabrica" 
resultados y permite gestionar su evolución. Está compuesto por módulos que, 
al no estar integrados entre sí, requiere mantenimiento manual para 
sincronizar información como versión/milestone<->tag, bugs que desencadenan 
cambios de versión, relación de tareas con bugs, etc.
Conviene tener en cuenta que cualquiera de las herramientas citadas tiene sus 
"best and worst practices". Por ejemplo, yo me he basado en las discusiones 
del grupo de desarrollo de Bugzilla (v2.17+) y en mi propia experiencia para 
recomendar las siguientes pautas:

*Estimaciones*
Cada bug nuevo, Bugzilla espera que se proporcione una estimación del tiempo 
necesario para resolver el bug. Una vez creado, Bugzilla indica mediante una 
tabla la estimación original, el tiempo dedicado hasta el
momento, el que falta, y la actual (calculada en función de éstos últimos).
No se podrá cerrar el bug (pasarlo a FIXED) a no ser que se fije el tiempo
restante a 0.

*Flags*
Es útil que el administrador cree un flag para Maven. Los flags son 
simplemente atributos de cualidades del bug en lo referente a un concepto en 
concreto. Los flags pueden tener los siguientes valores, "-", "?", "+" o en 
blanco. Para el caso de Maven,
* "-" indicaría que no es necesario que Maven haga referencia al bug como 
tarea o subtarea relevante.
 * "+" indica lo contrario, que aparece o debe aparecer en Maven.
 * "?" indica que a priori no se ve una postura clara sobre su referencia en
Maven.
 * " " No debe usarse en la medida de lo posible, ya que no ofrece
información.
Este flag es útil para que el gestor de proyecto o rol similar decida qué debe 
aparecer en Maven, y hacer que efectivamente lo haga.

*Keywords*
Son palabras claves (metadatos) predefinidos que pueden asociarse al bug o no.
Suelo usar los siguientes:
 * f-r -> functional requirement. Responde a un requisito funcional del
producto.
 * nf-r -> non-functional requirement. Análogamente, se trata de un requisito
no funcional.
 * doc -> documentation. Indica que el bug tiene impacto en la documentación
del proyecto. O bien necesita actualizarse, o añadir un comentario sobre el
tema del bug, o corregir algún punto incorrecto.
 * deploy. Sirve para indicar que el bug implica consideraciones en el
empaquetado o paso a producción de la aplicación.

*Status whiteboard*
Son datos "sticky" asociados al bug. A priori, están sujetos al criterio de la
persona que realiza la modificación en el bug. Se podría pensar en usar para 
indicar datos no esenciales como "fallo viernes 12/12 proceso renovación", o 
"userid=12345". Puede servir asimismo para buscar el bug conforme a algún 
dato relevante, que pueda ser común a más de un bug (si sólo fuera relevante 
para un bug se podría pensar en utilizar el alias del bug).

*Alias*
Nombre que identifica el bug, más "humano" que el bugid. Obviamente, no se
puede repetir, y tampoco permite utilizar espacios.

Tanto los keywords como el status whiteboard (que no sé cómo están traducidas
en castellano) se pueden utilizar en las búsquedas, no así los flags o los
aliases.

*Versiones*
Las versiones de un producto se refieren a releases ya existentes. Por esta
razón, un bug asociado a una versión concreta implicaría la existencia de un
branch en el cvs, en el cual se resolvería el bug. El nombre de la versión
puede ser bien directamente el tag, tipo proyecto-x_y o directamente x.y.

*Milestones*
Los milestones se refieren a la iteración en curso o posteriores, que deben
estar documentadas previamente en Maven. Para crear un tag en el cvs
correspondiente a una release, todos sus bugs deberán:
- -estar cerrados, o
- -estar asociados a la versión de la release (dando por suspuesto que se habrá
creado dicha versión en el bugzilla, y que el tag será un branch), o
- -haberse trasladado a releases posteriores.
El nombre de los milestones en bugzilla seguiría la misma nomenclatura que las
versiones.

Entrando en más detalle sobre qué ficheros actualizar de Maven, yo aconsejaría 
que cada commit representativo en el cvs, bien sea porque se ha resuelto 
algún bug o porque se ha avanzado en algún sentido, se indicase en el 
index.xml de Maven. En caso de que los cambios cierren tareas o subtareas 
declaradas en el tasks.xml, tales cambios deberían aparecer asimismo en el 
changes.xml. En el caso de que con dichos cambios se dé por finalizado un 
release, se deberá:
 -actualizar la versión de faq.fml y project.xml.
 -ejecutar "maven site" para comprobar que no hay errores en los ficheros xml
de Maven que se han actualizado
 -crear un jar con la aplicación para ese release, con el nombre
"proyecto-x.y.z.jar"
 -subir dicho jar al repositorio remoto de Maven.

Es conveniente aclarar lo que Maven es y no es. Maven es un repositorio, un 
sistema de plugins, y un generador de intranets, que "simulan" una 
integración de Bugzilla con CVS. No es un servidor que se ejecuta en runtime, 
que hace polling al cvs ni que haga ningún tipo de operación por sí mismo.
Maven empezó por la inconveniencia de subir binarios al cvs y va camino de ser 
un wizard que ofrezca todos los datos extraíbles sobre el qué es un proyecto 
y cómo se llevó a cabo.

Espero que te ayude en algo.

Un saludo,
Jose.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFAvhHCCAvt6RF8M0cRAhnPAJwPX9ugQIs1O4gE/F3UPATtLTs6eACfVelq
+CfrX7XXwC8BzJAvSUvoRWU=
=KtgK
-----END PGP SIGNATURE-----