Hay un problema al crear una versión con ramas de Git (Hub).
Estamos sirviendo una aplicación Node.js y operando una política de ramas en GitHub como:
main
: Base de lanzamiento del entorno de producción.develop
: Base de lanzamiento del entorno de desarrollo (beta).
Básicamente, estamos escribiendo código en una nueva rama desde la rama develop
y fusionándolo con develop
, luego fusionamos develop
con main
.
En casos de hotfix, solucionamos un código en una nueva rama desde main
y luego lo fusionamos con develop
y main
.
La versión se procesa mediante semantic-release y cambia automáticamente el archivo package.json
y CHANGELOG.md
en el pipeline CI/CD.
Lo cual significa que semantic-release hace un commit a la rama objetivo del lanzamiento y el archivo cambia.
Entonces, tenemos un problema en el siguiente caso:
- Si hay cambios en la rama
develop
, se incrementa una versión como beta. - Si hay hotfixes en la rama
main
, se incrementa una versión. - Al fusionar
main
endevelop
, ocurre un conflicto.
> Porque los archivos cambian y se comprometen al mismo tiempo.
> Este caso intenta reflejar la versión más reciente en la ramadevelop
.
> Esperamos el mismo fenómeno al fusionardevelop
enmain
.
Nos sentimos molestos por tener que solucionar este conflicto y preocupados por el cambio incorrecto que pudo haber ocurrido en este caso.
¿Deberíamos NO FUSIONAR main
en develop
?
Nos gustaría saber cómo construyes tu pipeline de lanzamiento.
Gracias.
davy.ai
Solución para el conflicto al fusionar
main
endevelop
Para evitar conflictos al fusionar
main
endevelop
, podemos seguir los siguientes pasos:develop
llamadarelease-x.x.x
. Aquíx.x.x
es el número de versión siguiente que planeamos lanzar.develop
a la ramarelease-x.x.x
.package.json
yCHANGELOG.md
.release-x.x.x
.release-x.x.x
en las ramasdevelop
ymain
.release-x.x.x
.Este proceso ayudará a evitar conflictos y asegurará que la versión de producción sea probada a fondo antes de fusionarla en la rama
main
.Canalización de Lanzamiento
Nuestra canalización de lanzamiento involucra los siguientes pasos:
develop
.develop
.package.json
yCHANGELOG.md
y crea una nueva etiqueta en el repositorio de git con el número de versión correspondiente.release-x.x.x
a partir de la ramadevelop
.package.json
yCHANGELOG.md
y crea una nueva etiqueta en el repositorio de git con el número de versión correspondiente.release-x.x.x
en las ramasmain
ydevelop
, y se elimina la rama.Siguiendo esta canalización, podemos asegurar que los cambios de código son probados a fondo antes de implementarlos en producción y evitar conflictos al fusionar
main
endevelop
.