¿Cuál es la mejor manera de generar un registro de cambios de lanzamiento preciso?

Estoy trabajando en algunos proyectos en los que me gustaría proporcionar un registro de cambios preciso con cada lanzamiento, pero no he encontrado un método para recopilar el registro de cambios que funcione sin problemas. El problema es principalmente cuando el tiempo entre versiones es largo y cada versión se entrega con muchas características y correcciones de errores, y cuando el software tiene varias ramas en desarrollo al mismo tiempo.

Algunas opciones que he considerado:

1. Cree el registro de cambios a partir de mensajes de confirmación y solicite a los desarrolladores que escriban los mensajes como si estuvieran escribiendo una línea para el registro de cambios (lo que efectivamente harían).
   • Es posible que no funcione cuando hay varias ramas y se fusionan entre ramas (puede ser difícil saber qué confirmaciones terminaron en la versión).
2. Requerir que para cada cambio en el código debe haber un ticket correspondiente en el sistema de seguimiento de errores. El registro de cambios podría escribirse en función de los tickets.
   • Los desarrolladores pueden encontrar frustrante hacer un ticket incluso para cambios menores, especialmente si hacer que el ticket lleve más tiempo que solucionar el error.
3. Exija que los desarrolladores siempre actualicen el registro de cambios (como un archivo de texto en la raíz del proyecto) al mismo tiempo cuando realizan cambios en el código.
   • Se siente como mano de obra que podría automatizarse.
4. Haga que el gerente del proyecto tome la diferencia de la versión actual y la anterior y escriba el registro de cambios en ese punto en función de lo que ve que ha cambiado.
   • Trabajo adicional para la persona responsable del lanzamiento y podría no ser obvio cuál es el efecto práctico de un cambio con solo mirar el código.
5. Envíe solo las características que se han planeado para el lanzamiento; puede escribir el registro de cambios incluso antes de comenzar a codificar.
   • No es una opción real a menos que esté utilizando el modelo de cascada.

He usado cada uno de estos o una variación de ellos en el pasado, pero han sido demasiado poco confiables, laboriosos o rígidos. ¿Alguien tiene una bala mágica o buenas ideas sobre cómo resolver el problema?

Si aún no tiene el requisito de un ticket para cada cambio, entonces hacer que los desarrolladores creen un ticket para cada cambio lo suficientemente importante como para terminar en el registro de cambios parece razonable.

Si el cambio es lo suficientemente significativo como para informar a los usuarios, entonces es probable que desee realizar ese cambio bajo un ticket de todos modos, y escribir tickets descriptivos es una buena práctica. Además, puede vincular esto con cualquier versión de lanzamiento y soporte de hoja de ruta que tenga su rastreador de errores.

Se siente como mano de obra que podría automatizarse.

¿Cómo podría ser automatizado? No es necesario editar el registro de cambios en cada confirmación, pero solo cuando se agrega una característica que vale la pena mencionar. ¿Sucede eso tan a menudo en su software que es una molestia agregar una línea al registro de cambios cada vez?

Podría decir que este es el deber del control de calidad de mantener actualizado el registro de cambios, pero algunos sistemas de gestión de configuración de software o rastreadores de problemas pueden generar el registro de cambios automáticamente, lo cual es útil en un entorno de desarrollador múltiple. Esto supone que está utilizando la función / seguimiento de problemas de la manera prevista.

Por ejemplo, el rastreador de problemas de código abierto Trac tiene un ChangeLogMacro .

Otros rastreadores de problemas pueden tener una macro o un complemento que puede generar el registro de cambios por usted. Por lo general, es una simple consulta de seleccionar todos los tickets / problemas que se han cerrado entre la última versión y la versión actual.