Estructura de Ramas en los Repositorios

Introducción

Para el equipo de Proyectos de GM Transport es importante minimizar al máximo los tiempos de desarrollo y despliegue de las aplicaciones, para ello se ha decidido implementar una metodología DevOps. Que constituye con un flujo de trabajo que permite a los equipos de desarrollo y operaciones trabajar juntos para producir software de alta calidad de manera más eficiente.

Aunque el objetivo es realizar un rapido despliegue, tambien se busca de forma activa reducir el minimo de denegados de calidad con el fin de realizar constantemente prubeas de integracion y despliegue.

Estructura de Ramas en los Repositorios

Para el control de versiones de los proyectos se ha decidido utilizar el siguiente esquema de ramas:

• master: Rama principal del proyecto, contiene el código fuente de la versión estable de la aplicación.
• qa: Rama de calidad, contiene el código fuente de la versión en pruebas.
• dev: Rama de desarrollo, contiene el código fuente de la versión en desarrollo.
• dev-<{Nombre de la tarea}>: Ramas de desarrollo de tareas específicas.

Con la existencia de las tres ramas principales, se busca tener un control de versiones de los proyectos, donde la rama master es la rama principal del proyecto aqui es despliegue directo a produccion, la rama qa es la rama de calidad donde se realizan pruebas de integracion y despliegue y la rama dev es la rama de desarrollo donde se realizan las tareas de desarrollo.

Pero con el fin de brindar libertad y flexibilidad al desarrollador, tambien viene incluida la rama comodin dev-<Nombre de la tarea> donde el desarrollador puede realizar sus tareas de desarrollo sin afectar el flujo de trabajo de las ramas principales y ver desplegada su tarea en un ambiente de pruebas de forma rapida.

Rama Master

Como se menciono anteriormente la rama master es la rama principal del proyecto, donde se encuentra el codigo fuente de la version estable de la aplicacion, esta rama es la que se despliega directamente a produccion, esta rama solo llegara al punto de estabilidad una vez que se hayan realizado las pruebas de integracion y despliegue en la rama qa y dev. La razon de pasar por dos filtros de pruebas de cada rama es con el fin de reducir al minimo los errores en produccion.

Aunque este mismo proceso pueda requerir mas esfuerzo y tiempo, se busca reducir al minimo los errores en produccion y garantizar la calidad del producto al maximo posible. Es por ello, que aunque suene redundante el flujo de multiples pruebas, se busca garantizar la mejor version del producto en produccion.

Rama QA

La rama qa es la rama de calidad, donde se realizan las pruebas de integracion y despliegue de la aplicacion, esta rama es la que se despliega en un ambiente de pruebas para que el departamento de calidad pueda realizar las pruebas necesarias para garantizar la calidad del producto, donde ademas se busca que calidad realice sus pruebas automaticas y manuales y sea una iteracion de pruebas continuas donde asegurando de lado de calidad una prueba automatizada con eficiencia del 100% se agregue al contenedor de calidad como una prueba mas que siempre se ejecutara cuando se realice un despliegue en la rama qa.

Para este proceso se busca la cooperacion activa de los desarrolladores y el departamento de calidad, aunque es un esfuerzo por ambas partes, puede ser beneficioso de forma bilateral.

Rama Dev

La rama dev es la rama de desarrollo, donde se realizan las tareas de desarrollo de la aplicacion, esta rama es la que se despliega en un ambiente de desarrollo para que el desarrollador pueda realizar las pruebas necesarias para garantizar la calidad de su tarea, donde ademas se busca que el desarrollador realice sus pruebas automaticas y manuales y sea una iteracion de pruebas continuas donde asegurando de lado del desarrollador una prueba automatizada con eficiencia del 100% se agregue al contenedor de desarrollo como una prueba mas que siempre se ejecutara cuando se realice un despliegue en la rama dev.

El esfuerzo presentado en la rama dev es el esfuerzo del equipo de desarrollo, ya que aqui conviviran las pruebas de desarrollo de todos los demas, donde no se aprobara el despliegue a la rama qa si no se ha pasado de forma exitosa todos los test de desarrollo realizado por todo el equipo. El proposito de porque se realiza este proceso es para garantizar que la rama dev no se rompa a causa de los cambios de otros desarrolladores.

Nota: Es importante mencionar que el flujo de trabajo de las ramas dev y qa es el mismo, donde se busca realizar pruebas de integracion y despliegue de forma continua, pero con la diferencia que en la rama dev se realizan las pruebas de desarrollo y en la rama qa se realizan las pruebas de calidad.

Rama Dev-<{Nombre de la tarea}>

La rama dev-<Nombre de la tarea> es la rama de desarrollo de tareas especificas, donde el desarrollador puede realizar sus tareas de desarrollo sin afectar el flujo de trabajo de las ramas principales, esta rama es la que se despliega en un ambiente de desarrollo para que el desarrollador pueda realizar las pruebas necesarias para garantizar la calidad de su tarea, donde ademas se busca que el desarrollador realice sus pruebas automaticas y manuales y sea una iteracion de pruebas continuas donde asegurando de lado del desarrollador una prueba automatizada con eficiencia del 100% se agregue al contenedor de desarrollo como una prueba mas que siempre se ejecutara cuando se realice un despliegue en la rama dev-<Nombre de la tarea>.

Vease este flujo de rama como la manera unica de realizar una tarea de desarrollo sin afectar el flujo de trabajo de las ramas principales y ademas una manera de experimentar el flujo de trabajo de las ramas principales sin afectar el flujo de trabajo de estas mismas.