GitOps
Tags: webdev, git, devops
Published: 2022-10-03 16:27:26

![gitops](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/czsferm2phafh86ss60o.png)

> **✨ Concepto clave**
> **GitOps** es una práctica donde los equipos mantienen sus procesos DevOps (Integración Continua y Despliegue Continuo), en un único recurso de verdad, Git.

## Vistazo General

Como colaboradores de algún proyecto de software, muy posiblemente estén familiarizados con el uso de Git.

> Un proyecto de software es un jardín, que necesita ser atendido y cuidado.
> 

El objetivo de GitOps no solamente es el resultado de un DevOps coordinado, sino de aquellas etapas de integración, fases de revisión de código y estado de salud de nuestro proyecto en curso.

## Flujo de Trabajo (Workflow)

> **✨ Concepto clave**
> Me refiero al **flujo de trabajo**, a aquello que nos permite mover una aplicación en desarrollo a producción, el ciclo de vida de las aplicaciones y las configuraciones que caracterizan a nuestra infraestructura.

Cada industria conoce sobre lo que es adecuado y/o las mejores prácticas concernientes a su mercado. En el software, podemos encontrar muchas estrategias, algunas veces llamadas patrones y/o frameworks, que expresan reglas como estándar, dejándolas a su interpretación e implementación.

Por ello, te comparto algunas relacionadas al flujo de trabajo mediante Git.

### Git Flow Branch Strategy

> **ℹ️ Definición**
> En **Branch Strategy**, la idea principal es aislar nuestro trabajo en diferentes tipos de ramas que generalmente entregan una cierta versión de nuestro producto.

Como colaboradores de proyectos en software, seguramente hemos trabajado con la estrategia de flujo mediante ramas, las cuales generalmente configuramos como:

- **Master**
   Cuyas alternativas pueden ser ***Production*** o ***Main***.
- **Release**
    Cuyas alternativas podemos tener ***Development***, ***Testing*** o ***Staging***.
- **Action**
    Cuyas alternativas podemos tener ***Integration***, ***Hotfix*** o ***feature***.


![branch_strategy](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/f4nbynheqvnbtd66yyiv.png)

 Los beneficios que ganamos serían:

1. Al tener diversos tipos de ramas (principales o de apoyo), hacen que sea fácil e intuitivo organizar nuestro trabajo.
2. Del efecto anterior, se puede proveer de un proceso de desarrollo de pruebas eficientes.
3. Se puede soporta múltiples versiones de código.

Los retos, por su parte, dependerán de:

1. Dependiendo de la complejidad, a veces de la madurez por concepción del producto o proyecto, podría complicar el proceso no lineal de desarrollo por falta de etiquetas de referencias.
2. Debido al poco control o coordinación entre los colaboradores, el historial de commits podrá limitar la identificación del cambio, desde la descripción hasta la atomicidad de cambios por registro.

### Git Flow Feature Strategy

> **ℹ️ Definición**
> En **Feature Strategy**, nuestras ramas principales contienen versiones finales que fueron integradas y/o desplegadas; en otras ramas (**features**), tendremos acciones que se desplegarán y fusionarán a los entornos y ramas principales, respectivamente.

Como colaboradores, utilizamos esta estrategia de trabajo para liberar características, despreocupándonos del entorno a desplegar ya que la misma rama posee la capacidad de despliegue al entorno personalizado (**feat.1.0-dashboard**) o como de release (**production**).


![feature_strategy](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/l6lhbhliqo68mkhc5dyq.png)

Como beneficios, tendríamos:

1. Al aislar la característica en una rama, no mezclamos los historiales de origen, evitando el efecto dominó entre ramas.
2. Con cada modificación, se puede desplegar, detalladamente, características al entorno deseado.
3. Al ser una estrategia independiente entre características, en proyectos basados en sprints, se podrá agrupar y visualizar versiones y sus respectivos efectos individuales.

Los retos, por su parte, dependerán de:

1. Una estrategia madura en el versionado del código, por ejemplo Semantic-Version sobre Git.
2. La falta de sincronización entre ramas origen, dejan sin comunicación entre características o dependencias relacionadas.
3. Se requiere madurez en DevOps para personalizar tanto el despliegue como destrucción de entornos.

## Beneficios de GitOps

> **✨ Concepto clave**
> Estamos de acuerdo que, cada cambio modificará el estado de la versión en nuestro repositorio, los cuales, una vez aprobados, se mezclaran a un destino que eventualmente marcará una nueva referencia de estado.

1. Experiencia de desarrollo (Development Experience XD)
   - Interiorice el proceso de desarrollo en su equipo u organización, vinculando a los colaboradores con herramientas familiares como Git, permitiendo su adopción de manera individual.
2. Resiliencia y tolerancia a errores (Site Reliability Engineering SRE)
   - Si su entorno está inactivo debido a la última implementación, simplemente puede usar Git para volver a la versión anterior.
3. Seguimiento de procesos (Issues Tracking)
   - Dado que todo tiene que suceder a través del repositorio de Git, todos los cambios en el sistema son completamente accesibles a través del registro de Git. Es fácil ver quién, cuándo y, exactamente, qué cambió de una versión a otra.
4. DevOps unificado
   - Con GitOps, las organizaciones pueden administrar toda su infraestructura y el ciclo de vida de desarrollo de aplicaciones utilizando una única herramienta unificada. Esto permite una mayor colaboración y coordinación entre los equipos, dando como resultado que haya menos errores y una pronta resolución de problemas más rápida.

## Conclusión

GitOps no es más que un sinónimo de automatización y registro, sus derivaciones hermanas pueden ser ChatOps e IssueOps, los cuales complementa nuestro flujo de trabajo y potencian nuestro ciclo de vida de software. Es por que el uso de una herramienta dependerá de la intención que conlleva en su implementación.