Versiones semánticas en Agile

Digamos que tengo 14 días de iteraciones de sprint donde tengo varias historias para nuevas características, pocas mejoras y algunos errores para corregir. También implemento esos cambios cuando están listos, no estoy esperando el final del sprint.

Mi problema es: ¿cómo hacer un seguimiento de las versiones semánticas de los productos desarrollados y mantenidos de esta manera? Si se lanzará cada 14 días, será fácil, aumentaré el número de versión y notaré todos los cambios en el registro de cambios. Pero, ¿qué pasa si los cambios se implementan continuamente? ¿Debería haber una versión aumentada cada vez que se implementa algo? ¿O debería esperar hasta que termine el sprint y después de esto, hacer un "currículum" y aumentar el número de versión solo una vez por iteración independientemente de la implementación real? ¿Cuáles son las mejores prácticas para el control de versiones semántico en Agile?

EDITAR: Para explicar mejor mis necesidades, quiero un registro de cambios para las partes interesadas en primer lugar. No creo que estén interesados ​​en un nuevo registro en el registro de cambios después de cada cambio implementado.

Para la administración de versiones típica, querrá que el sistema de compilación genere un número de compilación para que las DLL se versionen cada vez que se implementen. Esto asegurará que luego pueda verificar qué versión se implementa en un servidor determinado.

Su versión de 'marketing', que generalmente se incluye en notas de publicación o se publica en su sitio, no debe actualizarse en cada versión. Esas notas de lanzamiento deben acumularse y agruparse, probablemente cronometradas con el final de tu sprint.

Si el esquema clásico de versiones semánticas "MAJOR.MINOR.PATCH" tiene sentido, depende de a quién implemente, y especialmente cuándo y con qué frecuencia se implementa al usuario final . El esquema es más útil si trabaja con la versión estable "4.5", donde comienza con 4.5.0. Las versiones 4.5.1, 4.5.2, etc. contienen solo correcciones de errores, mientras que internamente ya trabaja en la versión 4.6.

Por ejemplo, si proporciona una "rama estable" a su usuario final, dele una versión 4.5.0 para la implementación inicial y 4.5.1, 4.5.2 cada vez que libere un parche. En su desarrollo interno "ágil" y la implementación de la mitad del sprint, ya puede tener una versión 4.6, simplemente llámela "versión beta". Siempre que lo implemente a mitad del sprint, agregue el número de compilación generado automáticamente como "4.6.beta build 123". Cuando finalice su sprint, asígnele "4.6.0" y cambie internamente el número de versión para el siguiente sprint a "4.7". Comenzar con ".0" es solo una convención, también puede usar ".0" para etiquetar versiones beta y comenzar con ".1" para sus usuarios finales. En mi humilde opinión, la palabra "beta" es mucho más expresiva, diciendo a todos que el sprint "aún no se ha completado".

Si publica un registro de cambios completo del usuario final con cada versión beta, depende de usted, pero al menos al final del sprint, el registro de cambios debe completarse, y cada vez que proporcione una corrección de errores al usuario final, también debe actualizar Los documentos de la historia.

Encontrará la estrategia de liberar dos ramas separadas, una rama "estable" con números de versión semántica y una "rama de desarrollo" marcada con números de compilación o algo similar, en muchos productos de código abierto como Inkscape, Firefox o 7-zip.

Sin embargo, si no trabaja con ramas estables y de desarrollo separadas, y lanza una nueva versión para su usuario final diariamente, también debe aumentar un número de versión diariamente. Para tal caso, los números de versión "4.5.1", "4.5.2", ... probablemente reflejarán sus implementaciones individuales, y no indican la diferencia entre las correcciones de errores y otros cambios. Eso puede estar bien, ya no es una clásica "versión semántica". En este escenario, también podría implementar las versiones 4.5, 4.6, 4.7, 4.8, que no ofrecen una diferencia real.

En cuanto a su pregunta sobre las entradas en su registro de cambios: en mi humilde opinión, cuando el usuario final puede ver algo, vale la pena ingresarlo en el registro de cambios, tan pronto como implemente el cambio. Por ejemplo, si usa la función alterna y realiza cambios en alguna función a medio cocer que aún no está activada para el usuario, eso no pertenece a un registro de cambios. Si solo refactoriza, sin cambios visibles para el usuario, eso no pertenece a un registro de cambios. Si corrige un error que podría haber afectado a algunos usuarios, eso definitivamente pertenece al registro de cambios, y debe mencionarse allí al mismo tiempo cuando implementa la corrección de errores. Y no importa si publicas diariamente, mensualmente o anualmente.

Usaría números de compilación. Por lo general, un número de compilación correspondería a la versión más alta del sistema de control de versiones. Si el número de compilación del lunes fue 1745 y se han verificado 5 cambios durante el martes, el número de compilación del martes por la noche sería 1750.

Luego haga un breve resumen de lo que ha cambiado entre 1745 y 1750.

Luego, cada vez que actualice el número de versión de su sistema, puede agregar todos los resúmenes breves de las compilaciones para obtener los cambios del último número de versión al nuevo.

Mi método preferido que he estado usando durante al menos algunos años ahora es aumentar el número una vez que se completa cada historia. Esto significa que las versiones lanzadas al final del sprint no serán continuas, por ejemplo, después de 1.2.3 puede encontrar 1.5.2 en lugar de 1.4.0.

En el registro de cambios, puede enumerar las versiones intermedias con sus descripciones correspondientes o simplemente agrupar todos los cambios en la versión "lanzada" y omitir las versiones intermedias.

Inicialmente, temía que los usuarios encontraran problemáticos los "agujeros" entre los números de versión, pero una vez que lo saben, no es un problema en la práctica. La gran ventaja es que aumentar el número después de cada historia hace que el proceso sea menos propenso a errores: no es necesario verificar todo el trabajo a partir de 2 semanas para decidir cuál será el próximo número de versión; al mirar una sola historia, es obvio . Además, los "saltos" en los números de versión entre cada versión dan una estimación aproximada de cuántos cambios se produjeron en la versión. En general, he encontrado que este sistema funciona bien (esto fue con clientes internos de la compañía, pero si ya trabaja en un ciclo de lanzamiento ágil, debería funcionar también para clientes externos).