¿La referencia al error / problema en el mensaje de confirmación se considera una buena práctica?

11

Estoy trabajando en un proyecto donde tenemos el control de origen configurado para escribir automáticamente notas en el rastreador de errores. Simplemente escribimos la identificación del problema en el mensaje de confirmación y el mensaje de confirmación se agrega como una nota al rastreador de errores.

Solo puedo ver algunos inconvenientes para esta práctica. Si en algún momento en el futuro el código fuente se separa del software de seguimiento de errores (o los errores / problemas reportados se pierden de alguna manera). O cuando alguien está buscando en el historial de confirmaciones pero no tiene acceso a nuestro rastreador de errores.

Mi pregunta es si tener una referencia de error / problema en el mensaje de confirmación se considera una buena práctica. ¿Hay otros inconvenientes?

programming-practices version-control issue-tracking

— Christian P
fuente

10

Hemos adoptado esta práctica y nos funciona muy bien. La estrecha integración entre el sistema de control de versiones (VCS) y otros sistemas que utilizamos, por ejemplo, integración continua, rastreador de errores, etc. es extremadamente valiosa. Si alguna vez cambiamos algo en el futuro, sin duda tendremos que evaluar los efectos secundarios, incluidos los enlaces entre el VCS y el sistema de seguimiento de errores.

En general, vería esto como una buena práctica. Para algunos sistemas de seguimiento hay opciones y herramientas adicionales disponibles, por ejemplo, propiedades de bugtraq para Subversion (SVN). Esto sugiere que bastantes personas ven valor en esta práctica.

— Manfredo
fuente

13

Si desea asegurarse de que no se pierda ninguna información, incluso si puede usar un rastreador de errores diferente en el futuro o si los datos del rastreador de errores desaparecen de alguna manera, ¿por qué no poner tanto el ID del problema como una breve explicación sobre el error? el mensaje de compromiso?

Solución de error # 123: la aplicación se bloqueó después de iniciar sesión

Entonces todavía tiene el enlace desde el historial de confirmaciones hasta el rastreador de errores, y si el rastreador de errores alguna vez no está disponible, aún puede ver en el historial de qué se trataba este error en particular.

— Christian Specht
fuente

Realmente hacemos eso, por lo que no tenemos que cambiar al rastreador de errores cada vez que navegamos por el historial de confirmaciones.

— Christian P

Bien, entonces lo dejaría tal como está. En mi opinión, esta es la mejor manera de hacerlo.

— Christian Specht

1

Si, buen punto. Sin embargo, esa era mi suposición de todos modos. Solo la identificación de error / problema por sí sola no es lo suficientemente buena en mi experiencia. Mirando el registro de confirmación, aún desea ver de qué se trataba cada confirmación, por ejemplo, cuál fue la razón principal de este cambio de código. A veces, el mensaje de confirmación es más técnico, mientras que el texto del sistema de seguimiento de errores está más dirigido a los usuarios del software.

— Manfred

En general, esta ha sido la práctica estándar en la que también he trabajado, creo que es la forma correcta de hacerlo.

— Carson63000

¡+1 siempre hace esto! Acabo de hacer el mantenimiento de un proyecto que está lleno de gemas como "esta puede haber sido la causa del error 5423" No tenemos acceso a su rastreador de errores.

— Kryptic

2

Esta es una práctica muy común, y me ha resultado extremadamente conveniente. Uso TRAC, por lo que puedo leer el historial del código y navegar a la tarea que generó el cambio, o leer el historial de la tarea y navegar a los cambios del código.

"Si en algún momento en el futuro ..." Si separa el código del rastreador de errores, entonces el antiguo historial de revisión probablemente no será de mayor interés.

— Kevin Cline
fuente

2

Yo también uso esta práctica y la considero muy buena. Pero además de la ID del problema, agrego una breve descripción del error / función (generalmente el título del sistema de seguimiento de errores). Esto a menudo ayuda a ahorrar tiempo porque no tengo que buscar en el sistema de seguimiento de errores (porque reconozco el cambio) Y, como dijiste, si de alguna manera pierdo el sistema de seguimiento de errores, no estoy completamente perdido.

— Nicolae Albu
fuente