¿Cuáles son los beneficios de la integración del código fuente para un sistema de seguimiento de errores?

Estoy eligiendo un sistema de seguimiento de errores / problemas para usar en nuestro proyecto. Esta pregunta y esta pregunta son útiles para evaluar los sistemas. Sin embargo, tengo una pregunta planteada al search en los diversos productos que se ofrecen.

Algunos sistemas promueven la integración del Sistema de Control de Código Fuente como una característica. Esto no es algo que haya usado antes y mirando los sitios web de varias herramientas. No puedo encontrar ningún detalle sobre lo que proporciona esta integración. ¿Es algo más que search en mi repository a través de la misma interfaz web que uso para generar errores?

Entonces, ¿qué beneficios ofrece tal integración? ¿Cómo me ahorrará time o mejorará nuestro producto?

Jira junto con FishEye (un browser SCM) puede, cuando si compromete un set de cambios con un post de logging que contiene una key de problema Jira, como "PROJ-123", inserte un enlace en el problema Jira correspondiente, y Jira mostrará un enlace en PROJ-123 al set de cambios que menciona ese problema.

Jira también puede integrarse con Hudson , de modo que cuando se realiza una compilation que incorpora una corrección (es decir, un set de cambios), el problema de Jira mencionado en el post de logging de esa confirmación reciba un comentario sobre el estado de la compilation.

Como un rastreador de problemas se utiliza para realizar un seguimiento de los problemas con el código fuente, hay una gran cantidad de características que uno podría imaginar en un sistema integrado de gestión de problemas / fuente.

La principal ventaja es que puede generar errores contra revisiones específicas del código fuente. Esto solo ayuda a identificar el estado de la base de código cuando se notó el error. Creo que un producto popular en este espacio es Trac , que se integra con SVN.

Lo hice con Visual Studio Team Foundation Server, que no solo se integra con el control de fuente, sino que también se integra con un almacén de datos. Esto le permite hacer un seguimiento, por ejemplo, de qué errores fueron causados ​​por qué piezas de código, mostrando qué piezas de código necesitan más QA. Las próximas funciones en la versión 2010 son aún más convincentes.

Bueno, yo diría que hay una razón importante aquí, y es que puedes trabajar en una forma orientada a tareas / problemas .

Quiero decir:

  • cada cambio de código que hagas (todo, desde una pequeña corrección rápida hasta una nueva característica grande) será un problema en Jira o Rally o Bugzilla, Trac, Mantis, el que más te guste.

  • Significa que el sistema de seguimiento de problemas / tareas debe ser fácil de usar, rápido, simple, etc., de lo contrario los desarrolladores lo odiarán

  • Luego asocie cada cambio al problema y listo. Obtiene la trazabilidad completa (ideal para la debugging de diferencias, se perderá si no la tiene), un mejor seguimiento del proyecto, una mejor gestión de versiones, etc.

Puede vincular cada set de cambios / confirmación (según su jerga scm) a una tarea, o, si su scm puede hacerlo, crear una twig para cada corrección de errores, que es aún mejor.

Básicamente lo que obtienes es simple: cada cambio será documentado, o al less vinculado al problema / tarea correcta.

Si usa twigs, puede promocionar cosas como: trabajar siempre en líneas de base estables, networkingucir la corrupción de la línea principal (o hacerlo prístino, si lo prefiere), decidir qué tareas integrar y cuáles mantener hasta la próxima versión, ejecutar testings individuales sobre los cambios antes fusión, y así sucesivamente.

Github es básicamente al revés: no tanto un sistema de seguimiento de errores / problemas con el control de la versión del código fuente incluido, sino más bien el control de la versión del código fuente con algún bug / seguimiento de problemas insertado. No puedo creer que nadie lo haya mencionado aquí, porque es mucho más común de esta manera al revés en estos días.

Pero es muy poderoso, básicamente puedes hacer reference a todo lo que git ofrece también en cuestiones: commits, branches, pull-requests. Github incluso tiene algunos "automágicos" instalados, fusionando un PR con contenido como "problema de arreglos # 23", cerrará automáticamente el problema # 23.

Github también es muy útil, porque la mayor parte del software de código abierto que se usa hoy en día también está alojado allí, y también puede hacer reference a todas esas bibliotecas en sus propios problemas / requestes de extracción, etc. También la mayoría de la infraestructura comercial moderna típica en torno al desarrollo de software también se integrará con Github: Travis o Codeship le dirá cómo funcionan sus comstackciones e incluso las desplegará automáticamente. Hound o Rubocop le dirán cómo se ve su código y Usersnap o Trackduck presionarán informes de errores en sus problemas de Github si no quiere usar su software.

Trac que se mencionó en las respuestas aquí se siente muy viejo si lo comparas con Github.