continuous-integration - registra - nota de credito requisitos

¿Cómo se generan notas de lanzamiento? (9)

Asumiendo que los desarrolladores no son corsarios y son parte de un equipo que obtiene asignaciones y las realiza, una lista de lo que se hizo y debería ser parte de UAT es la nota de lanzamiento de facto. Las listas de cambios de archivos y similares son irrelevantes y se pueden extraer de forma trivial del control de origen.

Ya que es muy difícil hacer cumplir una política de desarrolladores que verifican el código con números de problema, no me molesto. Lo pregunto en la revisión del código. También tengo una lista de lo que estamos trabajando. Las cosas que están hechas y hechas se agregan al registro justo antes de la versión mvn: se ejecutan los comandos de preparación. Luego lo camino a la QA y UAT.

Esto no es probable que alcance cientos de problemas por semana. En esos casos, es preferible un sistema más robusto.

[Pregunta]
¿Alguien ha publicado notas de producto a través de un proceso automatizado? Si es así, cómo. Especialmente con servicios de integración continua. ¿Utiliza un script para analizar los archivos de registro en busca de problemas solucionados para esa versión para crear el archivo de texto adecuado?

[Fondo]
Recientemente he implementado la integración continua para mis proyectos de hobby. Como parte de esto, he tenido problemas con el seguimiento de informes vinculados a mis versiones. Sin embargo, para los lanzamientos, deseo hacer lo mismo y hacer que produzca un archivo de notas de lanzamiento similar al nhibernate release notes.txt que encuentro muy limpio.

[Ejemplo]

Construir 1.2.1
Error arreglado:
* [ID-1] - The system doesn''t accept valid usernames
Mejoras:
* [ID-2] - Saving the file takes 3 minutes when it should take a few seconds.
Nuevas características:
* [ID-3] - Allow users to refresh the page using the F5 key.
Tarea terminada:
* [ID-4] - Document undocumented configuration properties.

En general, este tipo de cosas se realiza mediante el software de seguimiento de problemas. Realiza un seguimiento de cada nueva característica, cada corrección de errores y cada mejora, los asigna a un lanzamiento y luego genera notas de lanzamiento a partir de las descripciones.

En mi empresa utilizamos bugzilla. Utilizamos el hito para etiquetar un error con un número de versión específico. Luego generamos un informe xml para todos los errores con un hito específico y usamos un pequeño script para generar las notas de la versión.

Esto es algo que puede generalizarse fácilmente a cualquier software de seguimiento de errores, en general.

Supongo que también podría estar vinculado a los comentarios en los mensajes de confirmación en su sistema de control de versiones. Se podría hacer una consulta para enumerar todos los comentarios sobre las confirmaciones en el control de verson y luego filtrar todos los comentarios con una etiqueta específica.

Estoy luchando con los mismos problemas. En nuestro desarrollo, usamos svn / jira y tenemos una herramienta personalizada que intentará crear y evaluar los cambios de prueba antes de que se confirmen, y el desarrollo ingresa el número jira como parte de ese proceso (valida el número). Este número de jira se incluye en la confirmación SVN.

A partir de ese momento, generamos una nota de lanzamiento entre dos puntos en svn y, a partir de los comentarios, cada compilación puede generar una lista de problemas que se han comprometido y rellenar la nota de lanzamiento.

El problema con esto es que 1. los problemas en la nota de publicación deben ingresarse a medida que cambia el código. Los problemas resueltos sin un cambio de código no están incluidos. 2. Si un desarrollador está a mitad de camino de una solución, aparecerá en las notas de la versión cuando no debería hacerlo.

Quiero encontrar una solución con una sobrecarga manual mínima donde podamos tomar cualquier compilación de nuestro sistema CI y convertirla en una versión.

Estoy considerando la posibilidad de adaptar el proceso para que la nota de lanzamiento genere un error si no se cierra el problema, pero siento que los desarrolladores se quejarán de que podrían estar a mitad de camino, aunque es un problema cuando queremos hacer un lanzamiento.

La otra opción es incluir solo los problemas completados en la nota de publicación. Sin embargo, el problema con eso es que si un desarrollador corrige un problema en la versión A pero no lo solucionó en el momento en que se publicó A, y luego no realizó ningún cambio de código y cerró el problema después de que se liberó A, ¿cómo puedo incluir esto automáticamente? problema en las notas de la versión (puede ser que pueda buscar todas las jiras cerradas entre la versión A y B ...)

Gracias por leer

Hace poco enfrenté un problema similar y mejoré un plugin de Maven existente para hacer esto.

Si usa Git para el control de código fuente y construye su proyecto con Maven, entonces esta puede ser una buena solución: https://github.com/pankajtandon/maven-git-commit-id-plugin#releasenotes

Para aquellos que trabajan con .NET y TFS, puede usar TfsChangeLog para generar automáticamente sus notas de lanzamiento.

TFS ChangeLog permite a los usuarios de Team Foundation Server (TFS) extraer información relacionada con los conjuntos de cambios y los elementos de trabajo asociados en un formato XML que se transforma en HTML. TFSChangeLog produce automáticamente el registro de cambios / las notas de la versión en función del rango de conjunto de cambios seleccionado.
TFS contiene el historial de versiones de archivos a través de los conjuntos de cambios registrados y los WorkItems asociados. Esta información exacta se utilizará para generar notas de la versión. El administrador de configuración / publicación puede usar campos de datos del sistema o campos personalizados con el fin de generar contenidos de notas de la versión. El potente soporte de XSLT 2.0 para transformar datos de formato XML en bruto se proporciona de forma inmediata, lo que sin duda abre la posibilidad de generar datos en varios formatos. El soporte para XSLT 2.0 hace que sea muy fácil aplicar condiciones de filtrado para la salida de transformaciones según lo requieran los usuarios.

Podría hacer uso de una herramienta como doxygen para hacer esto, pero es un poco tedioso comentar de la manera que espera doxygen. Normalmente los consigo a mano.

No estoy seguro, pero ¿algo como FogBugz también haría esto?

Si está utilizando maven, existe el complemento de cambios de maven para este propósito y, por lo tanto, la producción de este informe podría automatizarse fácilmente en un proceso de integración continuo.

Si usa JIRA (lo cual sugeriría de alguna manera), puede generar automáticamente las notas de la versión para usted . El formato incorporado es bastante simplista, pero funciona bien en muchos casos. El contenido se puede personalizar hasta cierto punto, aunque esta no es la última palabra en términos de flexibilidad.

Si busca mejores notas de la versión de JIRA, pruebe el complemento de visualización de PDF . Eso:

algo más que una simple lista de "problemas completados" (por ejemplo, instrucciones de instalación y actualización, detalles legales, pruebas ejecutadas, archivos modificados)
más control sobre lo que se incluye (excluyendo ciertos estados, resoluciones, tipos de problemas, etc.)
permite distribuir su documento de Notas de la versión en correo electrónico (formato PDF) o impreso en papel

Descargo de responsabilidad: soy un desarrollador de este complemento comercial de JIRA.