METODOLOGÍAS GIT

Metodologías

GIT

Existen varias metodologías que se pueden utilizar en conjunción con GIT, una popular herramienta de control de versiones. Entre las mas comunes se encuentran:

GIT FLOW

FEATURE BRANCHING

TRUNK-BASED DEVELOPMENT

GITHUB FLOW

MASTER-ONLY FLOW

GITLAB FLOW

GIT FLOW

¿Qué es? Metodología de ramificación que propone una estructura de ramas bien definida para el desarrollo de software.

¿En qué se basa? Tener ramas separadas para el desarrollo de nuevas características, corrección de errores y lanzamiento de versiones.

Ramas de las que se compone:Ramas principales *Main (Master) *Develop

Ramas secundarias*Lanzamiento (Releases) *Características (Features) *Hotfix (Arreglo en Caliente xD)

FEATURE

MAIN

HOTFIX

RELEASE

DEVELOP

v1.0

v0.1

v0.2

Pros y Contras

• Fácil de comprender el flujo de ramas.

• No es el más indicado si tu proyecto necesita iterar muy rápido y subir a producción varias veces al día o semana.

• Ideal para productos estables que no requieren de desplegar cambios inmediatamente.

• En caso de que el proyecto utilice varias herramientas de integración continua, la rama develop puede convertirse en una rama redundante de main.

• Muy recomendable cuando el equipo tiene todo tipo de desarrolladores.

• El uso de la rama main como rama protegida. Muchas herramientas de automatización usan la rama main por defecto.

• El control de las features más la release hace que el código no se deteriore.

• Gran complejidad en las ramas creadas de hotfix y releases. La integración continua elimina la necesidad de la creación de estas ramas.

• Perfecto para productos open-source en los que pueden colaborar todo tipo de desarrolladores

FEACTURE-BRANCHING

¿Qué es? Esta metodología se centra en crear ramas separadas para cada nueva característica que se va a desarrollar.

¿En qué se basa? Cada desarrollador trabaja en su propia rama de características (Feature) y, una vez completada, la rama se fusiona con la rama principal (developer o main).

Ramas de las que se compone:Ramas principales *Main (Master) *Develop

Ramas secundarias*Características (Features)

MAIN

FEATURE

DEVELOP

v1.0

v0.1

Pros y Contras

• La rama main cambia constantemente porque los desarrolladores fusionan sus ramas de características como lo consideran conveniente. Esto puede dar lugar a features de larga duración que no se fusionan con frecuencia y pueden generan conflictos de fusión.

• No se interfiere o se sobreescribe el trabajo de otros desarrolladores porque se centra en su propia rama.

• Se puede accceder a las características de otros desarrolladores para coloborar e funciones.

• Los desarrolladores deben fusionarse pronto y con frecuencia.

• Dado que cada error vive dentro de su propia rama, los desarrolladores pueden usar ramas de funciones para ver qué problemas están en progreso y cuáles están listos para su publicación.

• Se debe crear un entorno para cada rama de función para que pueda probar de forma aislada, lo cual puede volverse poco práctico.

TRUNK-BASED DEVELOPMENT

¿Qué es? Metodología en la que todos los cambios se realizan directamente en la rama main y ocurren con mayor frecuencia.

¿En qué se basa? Las ramas feature se mantienen cortas y se fusionan frecuentemente en main. Esto promueve la entrega continua y una iteración rápida.

Ramas de las que se compone:Ramas principales *Main (Master)

Ramas secundarias*Características (Features) * Lanzamientos (Releases)

MAIN

FEATURE

RELEASE

V 1

Tag 2.1

V 2

Tag 2.0

Tag 1.0

Pros y Contras

• Promueve el usode una única rama (main) y desalienta la creación de múltiples ramas de características de largo plazo.

• Los cambios se realizan directamente en la rama main.

• Permite una entrega continua y una iteración rápida.

• Se confia en la capacidad de Git para manejar ramas cortas y fusiones frecuentes para evitar conflictos.

• Responde muy bien a proyectos agiles pequeños.

• El desarrollador debe ser responsable con su código y hacer el esfuerzo de subir código de calidad.

• Funciona muy bien co un equipo experimentado y cerrado.

• El proyecto debe tener QA y CD muy maduro, de lo contrario se introducirán muchos bugs en la rama trunk (main).

• Los desarrolladores siempre van a poder trabajar con el código más reciente.

GITLAB FLOW

¿Qué es? Metodología que propone utilizar main, ramas features y ramas develop.

¿En qué se basa? Una vez que una feature está finalizada hacemos una merge contra main. Una vez que se tienen varias features se lleva un merge a pre-producción. Y por último con la rama probada se hace merge a producción, de esta forma se consigue que el código subido sea estable, ya que se valida features tanto a nivel individual como en lote (pre-production)

Ramas de las que se compone:Ramas principales *Main (Master) *Pre-production *Production

Ramas secundarias*Características (Features)

produc

FEATURE

pre-pro

MAIN

MERGE REQUEST

MERGE REQUEST

MERGE REQUEST

MERGE REQUEST

MERGE REQUEST

Pros y Contras

• Mucha confianza en la versión de producción.

• Requiere de un equipo que valide los merges tanto de las features, como de los diferentes entornos.

• Ciclo de desarrollo muy seguro. Se revisa el código tanto a nivel individual en la feature, como a nivel global al pasar a preproducción o producción, mitigando el impacto.

• Tiempo demasiado alto para la entrega de valor. Desde que se crea y se valida la feature, hasta que llega a producción, tiene que pasar por muchas validaciones.

• Más complejo que GitHub Flow.

• Previene el "overheap" de crear releases, taggings, merge a develop.

GITHUB FLOW

¿Qué es? La diferencia principal con GitFlow es la desaparición de la rama develop.

¿En qué se basa?

• Todo lo que haya en la rama master debe ser desplegado.
• Para cualquier característica nueva, crearemos una rama de master, usando un nombre descriptivo.
• Debemos hacer commit en esta rama en local y hacer push con el mismo nobre en el server.
• Si necesitamos feedback, utilizaremos las herramientas de mergeo como pull request.
• Una vez revisado el código, podemos mergear contra master.
• Una vez mergeado contra master, debemos desplegar los cambios.

Ramas de las que se compone:Ramas principales *Main (Master)

Ramas secundarias*Características (Features) *Hotfix

MAIN

FEATURE

HOTFIX

FEATURE BRANCH

Pros y Contras

• Inestabilidad de master si no se utilizan las herramientas de testing/PR correctamente.

• Útil y amigable con las actuales herramientas de CI/CC

• Recomendado para features de duración corta (diarias o incluso de horas).

• No recomendado para múltiples entornos productivos.

• Flujo simple y ligero, recomendado si el proyecto requiere de una entrega de valor constante.

• Requiere un sólido marco de prueba automatizado y un proceso de lanzamineto automatizado.

• Dependiendo el producto, podemos tener restricciones de despliegues, sobre todo en aplicaciones Saas.

• Elimina la necesidad de las llamadas ramas de lanzamiento y los problemas de etiqueta de versión que se relacionan con esta.
• Menos posibilidades de que se acumule deuda técnica, ya que se puede abordar sin tantos gastos generales.
• Casi no se necesita ninguna administración de sucursales aparte de limpiar las sucursales de funcones una vez que se lanzan.

• No se presta bien a funciones grandes en las que varios desarrolladores deben trabajar en paralelo.

• Se necesita diligencia adicional ya que cualquier error fusionado en main irá directamente a producción.

MASTER-ONLY FLOW

¿Qué es? El flujo de trabajo usa solo una rama infinita.

¿En qué se basa?

• Se realiza cada feature o hotfix sobre la misma rama main, se testea y se hace commit en local. Una vez que este cambio se ha aprobado, se hace push contra main en origin, desplegándose en producción inmediatamente.

• Orientado a proyectos con desarrolladores muy experimentados y en el cual se fomente el pair-programming.

• Se deben usar features-flags (marcadores de funcionalidades) para poder integrar el código en la rama main y evitar conflictos a lo largo del tiempo.

Ramas de las que se compone:Ramas principales *Main (Master)

MAIN

USO DE FEATURES-FLAGS PARA COMMITEAR

Pros y Contras

• No soporta múltiples entornos productivos.

• Sólo se mantiene una rama.

• Requiere de desarrolladores experimentados para no dejar inestable la rama principal.

• Se tiene el histórico del proyecto limpio.

• El proyecto requiere de guidelines de código muy estrictas.

• Con el uso de pair-programming y desarrolladores experimentados, la entrega de valor en producción es inmediata.

Main (Master)

• Se debe procurar que el código de la rama main pueda estar disponible en cualquier momento para poder implementarse en producción.

Develop

• Rama que parte de main.
• Cualquier cambio realizado en las ramas de características (Features) se integran a esta.
• Cuando el equipo considere que la rama de funciones está lista después de una revisión exhaustiva, se fusiona exactamente donde la dejó por última vez en la rama main.

Main (Master)

• Contiene el código de producción

• Todo el código de desarrollo, a través del uso de releases, se mergea (fusiona) en esta rama en algún momento.

Feature

• Ramas feature de corta duración.

• Una vez que el código en su rama se compila y pasa todas las pruebas, se fusionan directamente en main.

• Se recomienda eliminar la rama.

Feature

• Por cada tarea que se realiza, se crea una nueva rama para trabajar en ella.
• Esta rama parte de develop.

Main (Master)

• Contiene el código de producción

• Todo el código de desarrollo, a través del uso de releases, se mergea (fusiona) en esta rama en algún momento.

Release

• Son indicadores que permiten que los desarrolladores envuelvan nuevos cambios en una ruta de código inactiva y la activen en un momento porterior.

Main (Master)

• Contiene el código de producción

• Esta rama se clona para generar una develop y sobre de esa realizar modificaciones.

Main (Master)

• Se debe procurar que el código de la rama main pueda estar disponible en cualquier momento para poder implementarse en producción.

Develop

• Contiene el código de pre-producción
• Cuando un desarrollador finaliza su feature, lo mergea contra esta rama.

HOTFIX

• Parte de master.
• Rama encargada de corregir una incidencia crítica en producción.

Feature

• Rama que se crea partiendo de main para poder trabajar.

• Se crea esta rama para desarrollar nuevas funciones o para corregir errores, las cuales siempre deben nombrarse con nombres descriptivos.
• Una vez que los cambios en la rama feature se revisan y aprueban, esta debe fusionarse con main.

Release

• Cada función constituye su propia versión y, por lo tanto, todo lo combinado debe estar en un estado desplegable.

Releases

• Parte de develop.
• Rama encargada de generar valor al producto o proyecto.
• Contiene código que se desplegará, y una vez que se han probado las features integradas en la release, se mergeará a la rama master.
• Esta rama debe ser eliminada una vez que se haya fusionado a main y a develop.

Feature

• Una nueva característica se desarrolla en su propia rama separada desde develop.
• Una vez que la característica está lista, se fusiona nuevamente con develop.
• Esto permite un desarrollo paralelo de múltiples características.
• Esta rama debe poder ser eliminada para evitar acumular demasidas en el listado de ramas.