Manejo del control de versiones en un entorno de integración continua

Question

¿Cómo se manejan las versiones en un entorno de integración continua donde hay una rama de desarrollo y una rama de versiones? Estoy usando git para que no haya una versión incremental del repositorio para usar. Parece que habrá versiones superpuestas, como 1.1.0 en la rama de desarrollo y 1.1.0 en la rama de publicación. ¿Acabas de agregar el texto "dev" o "liberar"?

Además, cuando crea una rama de publicación, ¿aumenta inmediatamente la rama de desarrollo al siguiente número de versión "propuesta"? Es posible que aún no conozca el próximo número de versión, pero si no lo incrementa, tiene 1.1.0 dev que contiene un nuevo trabajo no incluido en la versión 1.1.0.

Así que mi pregunta principal es ¿cuál es la relación en las secuencias de versiones entre estas dos ramas?

Tenga en cuenta que no estoy preguntando nada sobre cómo decidir qué números de versión usar. Intenté preguntar esto antes y seguí recibiendo comentarios como "incremento mayor para cambios de última hora", etc.

Answer 1

No tengo la versión de la rama dev. El devline es el tronco y periódicamente se ramifica desde dev a una nueva carpeta de lanzamiento. Entonces, la rama de publicación está llena de carpetas que son básicamente instantáneas de la línea de desarrollo.

IE, bajo la raíz que tiene/dev, /releases/0.1, /releases/0.2, /releases/1.0, etc.

No estoy seguro de si esto realmente responde a su pregunta.

Answer 2

Recomendaría establecer una actividad final para su entorno de CI para crear etiquetas. Creo que el comando git se parece a esto: git tag -a nombre

Utilizamos Major.Minor.Release.BuildNumber

aunque algunos lugares utilizan Major.Minor.Release.CheckinNumber

lo tanto, si quiero usar eso, entonces yo versionaría su rama de desarrollo, de lo contrario simplemente versionaría la rama de lanzamiento.

Answer 3

Si solo tiene una rama de desarrollo, es más efectivo hacer que sea la troncal y ramificarse de una rama de liberación cada vez que quiera estabilizar para liberarla. Si tiene múltiples proyectos de características, puede tener una rama para cada uno de ellos con la configuración de IC en ellos. Una vez que hayan terminado, los fusiona uno por uno con el tronco y una vez que todos se fusionan, se llega al primer escenario, donde se ramifica una rama de liberación fuera del tronco de nuevo.

En cualquier caso, no mantendrá la rama de desarrollo funcionando entre lanzamientos. Desea finalizarlo y comenzar uno nuevo para el desarrollo de la próxima versión. De esta forma, algunas de las características se pueden ramificar durante varias versiones si tardan más. Pero también no tienes demasiado lío en tus ramas de desarrollo.

Puede ramificar las ramas de desarrollo para la próxima versión tan pronto como haya ramificado la rama de liberación o incluso antes si así lo desea, pero generalmente es buena idea estabilizar para liberar, fusionar los cambios de la rama de liberación en el tronco y de allí a las ramas de desarrollo si haces eso. Si espera con la bifurcación después del lanzamiento, evitará algunas fusiones allí, pero ralentiza el desarrollo.