es.davy.ai

Preguntas y respuestas de programación confiables

¿Tienes una pregunta?

Si tienes alguna pregunta, puedes hacerla a continuación o ingresar lo que estás buscando.

Hay un problema al crear una versión con ramas de Git (Hub).

13 Jul, 2023 Programación

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 en develop, 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 rama develop.
    > Esperamos el mismo fenómeno al fusionar develop en main.

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.

Tags:  , , , ,

Answer

  1. Avatar for davy.ai
    davy.ai

    Solución para el conflicto al fusionar main en develop

    Para evitar conflictos al fusionar main en develop, podemos seguir los siguientes pasos:

    • Crear una nueva rama desde la rama develop llamada release-x.x.x. Aquí x.x.x es el número de versión siguiente que planeamos lanzar.
    • Hacer push de los cambios hechos en la rama develop a la rama release-x.x.x.
    • Utilizar semantic-release para actualizar automáticamente los archivos package.json y CHANGELOG.md.
    • Probar los cambios en la rama release-x.x.x.
    • Una vez verificado, fusionar la rama release-x.x.x en las ramas develop y main.
    • Finalmente, eliminar la rama 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:

    • Los cambios de código se realizan en una nueva rama desde la rama develop.
    • Se crean solicitudes de extracción para los cambios y los miembros del equipo realizan revisiones de código.
    • Una vez que los cambios son aprobados, se fusionan en la rama develop.
    • Desencadenado por la fusión, la canalización CI/CD ejecuta pruebas y compila la aplicación.
    • La canalización utiliza semantic-release para actualizar los archivos package.json y CHANGELOG.md y crea una nueva etiqueta en el repositorio de git con el número de versión correspondiente.
    • La canalización implementa la aplicación en el entorno beta para ser probada posteriormente por QA.
    • Una vez que QA aprueba los cambios, se crea una nueva rama llamada release-x.x.x a partir de la rama develop.
    • La canalización de nuevo utiliza semantic-release para actualizar los archivos package.json y CHANGELOG.md y crea una nueva etiqueta en el repositorio de git con el número de versión correspondiente.
    • La canalización implementa la aplicación en el entorno de producción.
    • Finalmente, se fusiona la rama release-x.x.x en las ramas main y develop, 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 en develop.

Comments are closed.