Introducción
A continuación, se presenta una serie de preguntas frecuentes que ayudaran a aclarar dudas sobre la estrategia de ramificación implementada.
¿Qué es una rama?
En GIT, una rama es una es una línea de desarrollo independiente que parte de un punto específico en la historia de un proyecto. Cada rama en GIT proporciona un entorno separado para realizar cambios, experimentos o nuevas características sin afectar directamente a la rama principal del proyecto u otras ramas. Cada rama tiene su propia historia de commits y puede ser fusionada con otras ramas cuando sea necesario. Las ramas facilitan el desarrollo paralelo y la colaboración entre equipos de desarrollo en un proyecto software.
Para saber más acerca de las ramas con las que se están trabajando en la estrategia de ramificación, vaya al siguiente epígrafe Estrategia de ramificación.
¿Qué es la rama main?
Representa la línea principal de desarrollo. Es donde se fusionan las nuevas características, correcciones de errores y otros cambios de todos los colaboradores. Tendrá el estado más actualizado del código estable.
Para saber más acerca de este tema, vaya al siguiente epígrafe Rama Main.
¿Dónde trabajo normalmente?
En tu rama feature, que normalmente, se generará a partir de main.
Para saber más acerca de este tema, vaya al siguiente epígrafe Rama feature o de características.
¿Qué son las ramas pru/pre/pro?
Son las ramas de entorno. Representan el código que se está ejecutando en un determinado entorno y se utilizará para orquestar los mecanismos de despliegue.
Para saber más acerca de este tema, vaya al siguiente epígrafe Ramas de larga duración.
¿Que es una rama “protegida”?
Es una rama en la que no se pueden realizar modificaciones directas, teniendo que pasar por algún mecanismo de control (por ejemplo, Merge Request), para poder integrar cambios en dicha rama.
Qué ramas estarán protegidas?
Las ramas protegidas son: main, pre y pro.
Para saber más acerca de este tema, vaya al siguiente epígrafe Ramas de larga duración.
¿Que es un Merge Request?
Un merge request (MR), también conocido como pull request (PR) en GitHub, es una solicitud que un desarrollador hace a un repositorio para que los cambios realizados en una rama de código se fusionen con otra rama, generalmente la rama principal, como la rama "main”. Los merge requests suelen incluir información detallada sobre los cambios realizados, como descripciones, capturas de pantalla, referencias a problemas o tareas asociadas y cualquier otra información relevante. Los miembros del equipo revisan el merge request, realizan comentarios, sugieren cambios y, una vez aprobados, se realiza la fusión de las ramas, lo que incorpora los cambios en la rama principal del repositorio. Este proceso facilita la colaboración entre los miembros del equipo, permite una revisión exhaustiva de los cambios antes de su incorporación y ayuda a mantener un flujo de trabajo organizado y controlado.
Para saber más acerca de este tema, vaya al siguiente epígrafe Técnicas a implementar.
¿Cómo integro los cambios con el equipo?
Abriendo un Merge Request a main
¿Quién puede solicitar los Merge Request?
Cualquier persona con rol Desarrollador o superior
¿Quién puede aceptar los Merge Request?
Cualquier persona con rol Mantenedor o superior.
¿Existe alguna restricción adicional para ejecutar un Merge Request?
Si, el pipeline debe finalizar de forma satisfactoria.
¿Qué pasa si no finaliza correctamente el pipeline y no se puede ejecutar el Merge Request ?
Hay que revisar la ejecución del pipeline. Si es por alguna no conformidad con algunas de las fases del pipeline, hay que subsanar el error correspondiente en la rama afectada y subir las correcciones a dicha rama para reintentar. Si es por cualquier otro problema, se debe cerrar el MR y generar otro nuevo.
¿Cómo despliego a TEST?
A partir de un TAG, creando una rama de ese tag y abriendo una MR de la rama creada, hacia el entorno de TEST.
Para saber los pasos necesarios para desplegar en el entorno de TEST, vaya al siguiente epígrafe Despliegue en el entorno de pruebas(test).
¿Qué es un TAG?
Un tag es una referencia a un punto específico en la historia de un repositorio. A diferencia de las ramas, que representan líneas de desarrollo independientes, los tags se utilizan para marcar versiones específicas del código en un repositorio. Al crear un tag, se puede asignar un nombre descriptivo, como una versión semántica, y asociarlo con un commit específico en la historia del repositorio. Esto permite a los desarrolladores y usuarios del proyecto identificar fácilmente versiones específicas del código y acceder a ellas en cualquier momento. Los tags también pueden ser útiles para la gestión de versiones, la generación de registros de cambios y la integración con sistemas de construcción y despliegue.
Para saber más acerca de este tema, vaya al siguiente epígrafe Tag.
¿Cuándo creo un TAG ?
Cuando se finaliza el desarrollo de todas las características acordadas para una determinada versión y estás están integradas correctamente en rama main. El tag se crea a partir de rama main.
¿Cómo despliego a PRE?
A partir de un TAG, creando una rama de ese tag y abriendo una MR de la rama creada, hacia el entorno de PRE. Luego, alguien de operaciones debe aceptar el MR.
Para saber los pasos necesarios para desplegar en el entorno de PRE, vaya al siguiente epígrafe Despliegue en el entorno de preproducción(pre).
¿Cómo despliego a PRO?
Exactamente igual que PRE, pero con PRO como rama destino
Para saber los pasos necesarios para desplegar en el entorno de PRO, vaya al siguiente epígrafe Despliegue en el entorno de producción(pro).
¿ Qué pasa hemos metido en PRO un fallo?
Se tienen varias alternativas para solucionar un error en producción:
(Preferente)Seguir el fuljo normal de trabajo, crear una rama desde main, hacer las correcciones y pruebas pertinentes y desplegar en el entorno de TEST, Pre y PRO. Para saber más acerca de este tema, vaya al siguiente epígrafe Entorno de pre-producción (pre).
Sacar rama de hotfix desde PRO. Cuando tengas solucionado el fallo, sacas un tag. Esperas al CI, y mergeas en PRO. Luego sincronizas con el resto de las ramas. La subsanación del error se tiene que incorporar a una nueva feature, sacada desde main, a la que se le añade el commit que corrige el error y se vuelve a integrar los cambios en main. Para saber más acerca de este tema, vaya al siguiente epígrafe Crear un hotfix desde la rama de producción(pro).
¿Puedo aceptar la MR hacia TEST sin involucrar otros equipos?
Sí
¿Puedo aceptar la MR hacia PRE o PRO sin involucrar otros equipos?
No
¿Puede el equipo de QA probar mi feature en el entorno de TEST?
Sí, pero el entorno de TEST no podrá ser empleado por el equipo de desarrollo para realizar nuevos despliegues hasta finalización de QA.
¿Cómo añado una variable de entorno a mi aplicación?
Editando el fichero de configuración correspondiente al entorno