Workflow

Flujo de GIT y testing

En la imagen anteriormente presentada, se pueden observar dos tipos de flujo.

Nueva feature

En el caso de comenzar el desarrollo de una nueva funcionalidad, se debe partir desde la rama Dev o QA (puede llamarse de alguna de estas dos maneras dependiendo la fase de desarrollo en la que estemos).

A partir de dicha rama, debe crearse otra que con su nombre referencie el desarrollo que se está llevando a cabo, es decir:

feature/[id-de-la-tarea]-[descripción-de-la-tarea]

// Ejemplo
feature/SW-7-variables-de-entorno

En dicha rama se escribirán los tests correspondientes a los criterios de aceptación de la funcionalidad, y nos debemos asegurar que un alto porcentaje de su coverage sea cubierto antes de enviar el código a ser probado.

Una vez nuestra solución esté "lista", podremos generar una Merge Request. En donde nuestro código será sometido a un pipeline de tests y una revisión por algún compañero desarrollador.

Bien, una vez finalizado este proceso de pruebas, el código puede ser Mergeado a Dev o QA. Donde un analísta de QA verificará si la solución es funcional.

Si el analista de QA da el OK, el siguiente paso es llevar nuestro código a una fase llamada Staged, donde la nueva funcionalidad será utilizada por un segmento pequeño de los visitantes de nuestra web, esta es la prueba final que realizaremos a nuestro código antes de desplegarlo en nuestro ambiente productivo.

Bug detectado

Este flujo es bastante similar al anterior con solo tres salvedades:

• La rama de partida es Master ya que el bug debe haber sido encontrado en Producción.

• La rama en la que se realizará el desarrollo deberá tener el siguiente formato.

hotfix/[id-de-la-tarea]-[descripción-de-la-tarea]

// Ejemplo
hotfix/SW-128-error-en-el-menu

• Debido a que no es una nueva funcionalidad, no es necesario probar la solución en Staged.