¿Cómo debo ramificar y etiquetar antes y después de un lanzamiento?

Question

He estado pensando en el proceso de implementación que estoy usando actualmente, y me pregunto si hay una buena manera de manejar la ramificación / etiquetado del código que se lanzará / ha sido lanzado a producción.

En algún momento quiero hacer una rama como la rama de lanzamiento y hacer cualquier cambio de último minuto en la rama y liberarla. Luego, después de lanzarlo, quiero guardarlo como etiqueta.

Para aclarar, estoy buscando convenciones para nombrar, manejar las ramas y el etiquetado. También me pregunto si hay alternativas a cómo estoy hablando sobre cómo manejar la situación.

• ¿Nombra las ramas de lanzamiento o usa la misma rama de lanzamiento con código nuevo cada vez?
• ¿Eliminar ramas de lanzamiento una vez que existan como etiquetas?
• ¿Cómo nombras tus ramas / etiquetas?

Answer 1

Sugiero leer esta respuesta

Administración de versiones en SVN

Básicamente tiene una rama llamada RELEASE que puede etiquetar desde allí si lo desea. Y mantenga la versión del código de última generación en el tronco

En lo que respecta a los nombres de las versiones: depende de lo que más le convenga y de quiénes son las personas que ven el número de versión.

Piense en usar MajorRelease.MinorRelease, entonces tal vez en algún lugar para los interesados ??técnicamente, incluso podría especificar un número de lanzamiento de parche (por ejemplo, las actualizaciones automáticas de la aplicación y major.minor permanece igual).

Mayor: grandes cambios - > nueva funcionalidad / compatibilidad de cortes Menor: compatible con la interfaz (por ejemplo, rendimiento) Parche: correcciones de errores

Answer 2

Puede usar la información aquí como guía, incluso si no está utilizando TFS.

Orientación de ramificación

Answer 3

Hay muchas formas de trabajar. El que uso es el siguiente:

project_repository
|
|- trunk //Where the current in support release is.
|
|- branches //Where new features/big fixes or refactors are made.
|
|- tags //Where all releases are tagged.
     |
     |- releases //where all release tags are located
     |- daily //where all daily tags are located.

Los nombres que usamos son los siguientes:

• Para las ramas, nombramos la rama por las tareas principales que se realizarán en ella (por ejemplo: admin_module_refactor).
• Para las etiquetas, nombramos las etiquetas con el número de versión (mayor.minor.micro. ej .: 1.0.2) cuando corresponden a una etiqueta de lanzamiento. O con la fecha de las etiquetas de trabajo diario (p. Ej .: AAA_MM_DD).

Para seguir esta estructura y convenciones de nomenclatura, tenemos un conjunto de herramientas y scripts que ayudan a trabajar de esta manera. También las etiquetas diarias son generadas por un servidor de compilación todas las noches.

Answer 4

Automaticé el proceso de compilación usando CruiseControl.Net. Teníamos las compilaciones correspondientes a los números de compilación, por lo que la versión dll sería 6.5.4.1234. Los 6 y 5 siempre se actualizarían manualmente cuando teníamos versiones mayores y menores. El 4 se actualizó manualmente después de una compilación (y el 1234 también se restableció a 0). El proceso de compilación siempre actualizaba 1234 a 1235.

Cuando lanzamos desde un enlace troncal (la versión siempre sería 6.0.0.x), lo ramificaríamos manualmente y lo llamaríamos Branch_6_0. La rama se construiría como 6.0.1. Trunk se movería a 6.1 o 7.0.

CruiseControl tenía dos modos (desarrollo y prueba). La prueba siempre se creó a pedido y crearía una rama correspondiente a la versión de compilación.

Answer 5

  

En algún momento quiero hacer una rama   como la rama de lanzamiento y hacer cualquier   cambios de última hora a la rama y   liberarlo

Esta es la parte que me preocupa. Por lo general, querrá hacer una rama, hacer todo su desarrollo en ella y luego reintegrar esa rama con el tronco. Crea tu etiqueta desde este punto en el tronco. Si desea realizar más cambios, cree una nueva rama, edite, reintegra y vuelva a publicar.

No intente realizar cambios en la rama de liberación, ya que puede perderlos o tener problemas para fusionarlos nuevamente con el tronco.

El enfoque alternativo para lanzar una bifurcación es realizar todos los cambios de desarrollo en el tronco y, cuando esté listo, crear una rama de lanzamiento / etiqueta. Para una pequeña tienda de desarrollo, esta suele ser la forma más fácil de hacerlo. (El otro enfoque funciona bien cuando realiza grandes cambios en un producto en el que todos los demás también realizan cambios).