Toda la confusión proviene de las diferentes semánticas que MS usa para "Número de compilación" y especialmente "Revisión". Los términos solo significan cosas diferentes.
La mayoría de las personas (incluido yo mismo) usan un esquema de numeración de versión semántica en el que solo obtienes un número de CREACIÓN más alto cada vez que tienes que hacer una nueva compilación por cualquier razón. Para nosotros, un hotfix se considera solo otro cambio de código, y la parte BUILD aumenta automáticamente con cada ejecución de CI. Los módulos con el mismo MAJ.MIN.REV se consideran intercambiables, y el BUILD le dice cuál es el más reciente.
Sin embargo, el aumento de REVISION indica una nueva rama de lanzamiento permanente, por eso la colocamos antes de BUILD. La desventaja de ese enfoque es que podríamos obtener la siguiente secuencia de eventos:
- commit número 4711: Alice agregó la función A
- CI produce la compilación 1.2.3.100
- commit número 4712: Bob modificó la característica B
- commit número 4713: Alice arregló la función A (la "revisión")
- CI produce la compilación 1.2.3.101
Como puede ver, la revisión no es el único cambio contenido en la próxima compilación, sino que la modificación de Bob se convierte en parte de esa compilación. Si desea estabilizar la rama actual, puede tener problemas ya que nunca puede estar seguro de si Bob acaba de agregar un montón de errores.
MS usa ambos términos de manera diferente. El número BUILD no se incrementa automáticamente, sino que se puede considerar como una especie de rama de lanzamiento, para congelar el código utilizado para una versión particular del código. La REVISIÓN indica cambios "en caliente" adicionales aplicados a esa rama BUILD. Por lo tanto, la secuencia sería la siguiente:
- commit número 4711: Alice agregó la función A al tronco / maestro
- Carl crea una rama de construcción
1.2.100
- CI produce la compilación 1.2.100.0
- commit número 4712: Bob modificó la función B en troncal / maestro
- commit número 4713: Alice arregló la característica A en la
1.2.100rama
- CI produce la compilación 1.2.100.1
El término REVISIÓN puede referirse a
- una revisión del producto (así es como la mayoría de la gente lo usa)
- una revisión de una compilación diaria particular (eso es lo que hace MS)
La diferencia clave entre los dos procesos es si desea o no la posibilidad de aplicar revisiones a las compilaciones de CI y, por lo tanto, en qué punto del proceso se realiza la ramificación. Este aspecto se vuelve importante cuando desea poder elegir una compilación en particular en cualquier momento después de que todas las pruebas tuvieron éxito y promocionar exactamente esa versión para el próximo lanzamiento oficial de su producto.
En nuestro caso, la herramienta CI crea una etiqueta de repositorio, por lo que siempre tenemos la información necesaria lista para usar, cuando sea necesario. Con SVN se vuelve aún más simple, porque las etiquetas y las ramas se implementan exactamente de la misma manera: una etiqueta no es más que una rama ubicada debajo /tags.
Ver también
Desde la sección de preguntas frecuentes en la estrategia de ramificación de TFS :
¿En qué rama debo arreglar el ticket P1 (hotfix)?
El P1 debe repararse en la rama más cercana a la base de código que se ejecuta en Producción. En este caso, el P1 debe repararse en la rama Prod. Al aplicar la corrección en cualquier otra rama y extender los cambios a la producción, corre el riesgo de liberar código semiacabado o no probado de las iteraciones posteriores.
Ahora puede discutir si es seguro trabajar directamente contra la rama Prod, piense de nuevo, un P1 que requiere atención inmediata no debería ser un problema fundamental en el sistema. En caso de que sea un problema fundamental, debe agregarse a la cartera de pedidos del Producto, ya que puede requerir más análisis y discusión con el cliente.
Otra buena lectura es la guía de ramificación TFS