SOP CRUCE - Git, GitLab, Deployment.

Standard Operating Procedure

💡 Procedimiento operativo estandarizado de implementaciones y flujo de trabajo con Gitlab para gestión de repositorios y despliegues de aplicaciones.

Objetivo

• Lograr una mejor organización de los repositorios y del flujo de trabajo.
• Establecer un acuerdo sobre los nombres y procedimientos para cada una de las ramas de Git, tanto locales como en la nube.
• Establecer reglas específicas por área (backend, frontend, delivery) y reglas diarias generales.

Alcance del documento

• Backend
• Frontend

---

Flujo Gitup base

---

Flujo GitUp Feature branches

Se propone implementar una estrategía de Git basada en Feature branches poniendo énfasis en las ramas:

• dev → Rama de desarrollo donde se deberán mergear los cambios a final del time gap obligatoriamente.
• main → Rama principal la cual representa exactamente el mismo contenido que se encuentra en PROD. Debe ser la rama más limpia.
• feature → Es un conjunto de ramas con X nombre según cada issue. Son ramas dinámicas que se crean en base las tasks.
• hotfix → Rama con cambios exclusivamente para corregir errores críticos de producción. Se mergea directo al master sin pasar por los procesos anteriores.

Sincronización de branches

En punto es importante conocer el flujo de Gitup explicado en esta documentación: GitUp

Para comenzar a trabajar en un Issue primero debemos sincronizar las ramas remotas y locales

Un Issue ingresa desde ClickUp a GitLaby se ve así:

Las ramas remotas son las que creamos desde la interfaz de GitLab al momento de mover un issue a su repositorio correspondiente. Siempre llevan el ID del issue generado en ClickUp, como se ve en la siguiente imagen:

A destacar que simplemente creamos una rama sin hacer el merge request . No es necesario porque aún no tenemos cambios que subir.

Con esto ya preparamos la rama remota.

Para poder sincfronizar la rama remota con la local desde nuestra terminal ejecutamos:

bash

git clone <tu-repositorio>

git fetch origin

git branch -a

git checkout -b <rama-destino> origin/<rama-destino

• *git fetch* actualiza tu repositorio actual con las referencias remotas
• *git branch -a* lista todas las ramas, incluyendo las remotas
• git checkout -b <rama-destino> origin/<rama-destino crea una rama local basada en una remota.

Debería verse algo similar a esto:

*en este caso tomamos como referencia development y el issue 86aznn4cu2.

¿Por qué simplemente no creo una rama desde la interfaz con el mismo ID del Issue?
si bien es posible (y ya lo hemos hecho antes), es mucho más seguro que utilicemos git fetch, ya que mantiene actualizadas las referencias internas de git. Cuando creamos una rama manualmente, sin sincronizarla, estamos "dejando a la suerte" las referencias de nuestros commits para que sean acordes a la rama remota.

DEVELOP BRANCH AREA

Los estados en el area de desarrolo, IN PROGRESS y QA corresponden a ramas dinámicas con alta frecuencia de commits.

En IN PROGRESS tenemos las feature branches, es decir, las ramas con el Issue ID de nuestra tarea.

En QA seguimos teniendo las mismas feature branches , pero con la capacidad de instalarse en ambientes de tipo stage. Si un issue llegó a QA, entonces debería solicitarse un merge request a la rama dev.

Este último es importante para mantenter el orden entre ramas y que evitar problemas como:

• Ramas cruzadas. Por ejemplo, cuando múltiples devs trabajan sobre el mismo issue.
• Contenido perdido. Por ejemplo, cuando un dev tiene el código solo en su rama local.
• Enviar a producción features que no están listos

La rama dev siempre debe estar al día y es posible que contenga cambios que aún no esten en producción . Esto ocurre cuando se cumple el time gap, donde cada desarrollador debe subir sus cambios pero no puede hacer un despliegue.

• **¿**Qué pasa si aún no terminé mi tarea y debo subir los cambios? en estos casos, nuestra tarea sigue en IN PROGRESS por lo tanto nuestros cambios deben quedar guardados en la feature branch (la branch con el ID del Issue).
• **¿**Qué pasa si mi tarea esta en QA? *siempre que estemos en este estado, nuestros cambios estan listos para evaluar , por lo tanto hay que hace un merge request a dev.

MAIN BRANCH AREA

Los estados IN REVIEW, REJECTED , CLOSED, corresponden a producción . Son estáticos por definición ya que la única forma de llegar a este punto es cerrando un issue (finalizar una task). De lo anteriormente mencionado, los últimos dos estados no influyen en las ramas que creamos.

Para que un cambio llegue a IN REVIEW , primero tuvo que haber pasado por un QA y segundo, por el CICD , el cual se encarga de llevar a cabo este proceso si nuestro repositorio tiene el archivo .yaml . Cuando este proceso termine, se despliegan los cambios al master y no es necesario usar la VTEX CLI.

Es sumamente importante revisar que la rama dev apunte main cuando vamos a subir los cambios a producción , de lo contrario el CICD no iniciará.

Mergear cambios de DEV a MAIN desde la interfaz

Una manera simple de pasar nuestros cambios más actuales a main , es a través de la interfaz siguiendo estos pasos:

1. Crear el merge request

   

2. Setear la rama origen de nuestro request dev a la rama destino main

   

3. Enviar el request completando los campos que sean necesarios. Importante asignar el Label Approved si no lo tiene.

   

Debería verse así:

• ¿Qué pasa si mi proyecto no tiene incorporado el CICD? En estos casos se realiza el procedimiento manual a través de la VTEX CLI explicados en esta documentación: Despliegue a producción

Time Gap

Simplemente es la brecha de tiempo en donde:

• Se actualiza la rama dev o feature según corresponda.
• No se despliega a producción.
• No se aceptan merge requests

La brecha para estos procesos comienza a partir de las 16:30hs. Ningún Issue puede quedar “suelto” a partir de este momento.