Cuando desarrollamos un proyecto de unas dimensiones considerables y además con varios desarrolladores nos enfrentamos a la tarea de esforzarnos más en la organización y, por supuesto, en los bugs que surgen. A veces tendemos a hacer una lista de los bugs, pegarlos como post-it en el tablón de Scrum, almacenar email con los bugs que detecta el equipo, etc..
Pero esto resulta ineficiente para realizar un seguimiento adecuado de lo que se resuelve en el repositorio y los nuevos milestone con cambios que se entregan al cliente. Así que usar un buen sistema de bug tracking es fundamental: Jira, Trac, Bugzilla, Pivotal Tracker, Team Foundation Server... son buenos ejemplos para usar un sistema de control del proyectos y de los bugs que surjan. Por eso nuestra pregunta de la semana va encaminada por este camino, descubrir cuál es el que se ajusta mejor a vuestras necesidades, de pago o no.
¿Cuál es vuestro sistema de bug tracking preferido/imprescindible?
La mejor de las respuestas se publicará la semana que viene. Recordad contestar en la zona de Respuestas (no en los comentarios de este post).
La semana pasada os preguntábamos ¿Cuál es tu sistema de control de versiones preferido: Subversion, Git u otro? Parece que Git ha ganado por goleada al resto de sistemas, sin desmerecer a Mercurial que también vemos que ha escalado posiciones. El que se queda atrás es Subversion que parece que cada vez menos desarrolladores apuestan por esta solución y prefieren sistemas distribuidos al estilo de Git o Mercurial. De entre todas las respuestas la mejor ha sido la de Ricardo Amores Hernández:.
Sin duda alguna Git: Sistema distribuido: todo el mundo tiene copia de todo el repositorio. Y aún así ocupa poco más que lo que ocupa una copia de trabajo en otros sistemas. Minimiza pérdidas de información y posibilita el… Trabajo en local: sólo si quieres pasar datos a un servidor remoto te conectas, si no quieres conectarte o no tienes conexión, aún puedes hacer commits (aka: guardar versiones) en local. También al tener una copia del repo accedes a toda la historia en local, con lo que puedes comprobar qué ha cambiado, quien lo ha cambiado y los diffs casi instantáneamente, al no necesitar conectarse. Es decir, que su mayor baza es la … Velocidad: Como casi todas las operaciones son locales va MUY rápido. Y en red gracias a comprimir y enviar sólo los paquetes con los cambio también es muchísimo más rápido. Y lo más importante: branches y merges que funcionan. De verdad. Resumiendo mucho, en cada commit Git guarda ‘snapshots’ del sistema, no una lista de cambios, por lo que puede recorrer la historia del repositorio y saber en qué momento la rama actual derivó de otra (entre otras cosas) con lo que dispone de más información para hacer los merges, y además la obtiene más rápido (recordemos que a la historia se accede localmente) Ahora puedes permitirte el hacer una rama por desarrollador o equipo, cada uno trabajando en una feature, mientras otro equipo corrige errores en otra, y con coordinación hacer merge de TODO en minutos, y no hora (o días). De hecho al ser distribuido y tener un sistema tan eficiente de merging y branching permite más y mejores workflows de trabajo, y no sólo el cliente-servidor de cvs / svn y demás. No he usado mercurial, pero creo que también está muy bien. Si bien creo que no es tan rápido como Git, también me comentan que la curva de aprendizaje es algo menor. svn y cvs están simplemente anticuados.
Agradecer a todos los que enviasteis respuestas, nos vemos la semana que viene.
En Genbeta Dev Respuestas | ¿Cuál es vuestro sistema de bug tracking preferido/imprescindible?
