GitOps: la evolución de los despliegues modernos en TI

Introducción

Los equipos solían publicar ejecutando scripts desde una laptop o conectando trabajos puntuales de CI. Eso funcionaba, hasta que Kubernetes, las topologías multiclúster y los múltiples equipos hicieron que “simplemente ejecuta el script” se volviera riesgoso y difícil de repetir.

GitOps toma otro enfoque: tratar Git como la fuente de verdad tanto para las aplicaciones como para la infraestructura, y dejar que un controller mantenga la realidad sincronizada con lo que está en Git. El resultado: menos entornos únicos e irrepetibles, menos credenciales de producción y cambios más rápidos y seguros.

Este artículo explica qué es GitOps, por qué ayuda, cómo funciona en Kubernetes y dónde encaja junto con CI/CD, IaC, DevOps y NoOps.

¿Qué es GitOps?

GitOps es un modelo operativo en el que:

• El estado deseado se almacena de forma declarativa en Git: manifiestos, Helm, Kustomize o Terraform.
• Un controller —por ejemplo, Argo CD o Flux— reconcilia continuamente el clúster para que coincida con ese estado.
• El drift se detecta y corrige, y para revertir basta con hacer un git revert.

En comparación con el CI/CD tradicional:

• CI/CD envía los cambios a los entornos desde los pipelines.
• GitOps extrae los cambios desde Git hacia los entornos mediante un controller de larga ejecución, que sigue reconciliando el estado.

Piénsalo como “infraestructura y aplicaciones como código”, con un robot que se asegura constantemente de que la realidad coincida con el repositorio.

Por qué los equipos adoptan GitOps

• Automatización y seguridad: menos pasos manuales; la reconciliación detecta drift y errores de configuración.
• Trazabilidad y auditoría: cada cambio es un commit, un pull request y una revisión. Es fácil ver qué cambió y cuándo.
• Recuperación rápida: revierte en Git y el controller restaura el estado anterior.
• Consistencia entre clústeres: una fuente de verdad y múltiples consumidores. Menos entornos únicos e irrepetibles.
• Mayor seguridad: ni los pipelines ni las personas necesitan permisos cluster-admin en producción; el controller extrae los cambios.

Donde ofrece más valor: varios servicios, clústeres y equipos; entornos regulados que necesitan auditabilidad y separación de responsabilidades.

Donde puede ser excesivo: una sola aplicación, un clúster y publicaciones poco frecuentes. Un pipeline sencillo puede ser suficiente.

GitOps durante el ciclo de vida

• Construir: crea entornos de desarrollo efímeros a partir de los mismos manifiestos. Facilita la incorporación de personas y reduce los “en mi máquina sí funciona”.
• Probar: ejecuta pruebas con configuraciones cercanas a producción —la misma base y overlays distintos— para tener menos sorpresas el día del lanzamiento.
• Desplegar: hacer merge a main actualiza los entornos. Los cambios pequeños y frecuentes reducen el riesgo; las políticas de autosync mantienen el flujo.

Un patrón práctico: un repositorio por aplicación (código de la aplicación y manifiestos) y un repositorio de entornos para la configuración de los clústeres. Cada caso puede variar (monorepo o varios repositorios); mantén clara la propiedad.

GitOps en Kubernetes: una forma de organizarlo

Repositorios

• Repositorio de infraestructura: Terraform, complementos del clúster, namespaces y RBAC.
• Repositorios de aplicaciones: código y manifiestos de Helm/Kustomize.
• Repositorio(s) de entornos: qué aplicaciones, qué versiones y en qué clústeres.

Controller: Argo CD (interfaz, SSO, patrón app-of-apps y sync waves) o Flux (CRDs nativos de Git y automatización de imágenes).

Flujo

1. Desarrollo abre un pull request que actualiza la versión de un chart Helm o un overlay de Kustomize.
2. Se revisa, pasan las comprobaciones y se hace merge a main.
3. El controller detecta el commit y reconcilia el estado.
4. Las comprobaciones de salud validan el rollout y el drift se corrige automáticamente.

Secretos: usa SOPS, Sealed Secrets o gestores de secretos externos. No confirmes secretos en texto claro.

Multiclúster: un controller por clúster; los repositorios de entornos definen dónde se ejecuta cada aplicación.

Consejo: muestra el SHA del commit de Git y la versión de la aplicación como labels o annotations en los workloads. Facilita mucho la depuración.

Comparaciones que te van a preguntar

CI/CD tradicional

• Ventajas: modelo mental sencillo y amplio soporte de herramientas.
• Desventajas: envíos únicos sin reconciliación; los pipelines suelen necesitar credenciales de producción.

Infraestructura como código (IaC)

• IaC define qué crear; GitOps define cómo mantenerlo continuamente en ese estado.
• Muchos equipos ejecutan Terraform mediante GitOps para detectar drift y hacer reversiones seguras.

ChatOps: es útil para aprobaciones y visibilidad. Combínalo con GitOps para que el bot inicie merges en vez de ejecutar kubectl.

NoOps: funciona en plataformas altamente gestionadas. La mayoría de los stacks reales siguen necesitando guardrails a nivel de clúster; GitOps ayuda a proporcionarlos.

Errores comunes y cómo evitarlos

• Dispersión de secretos: estandariza un único patrón (SOPS/Sealed Secrets/External Secrets) y documéntalo.
• Caos de “un repositorio gigante”: empieza en pequeño y luego divide según límites de propiedad. Aplica CODEOWNERS y revisiones.
• Reconciliación ruidosa: activa comprobaciones de salud y sync waves progresivas. Fija las versiones; evita latest.
• Ciclos de bootstrap: define una ruta clara para el bootstrap (por ejemplo, que Argo CD se configure a sí mismo con un manifiesto mínimo y versionado).

Plan de adopción de bajo riesgo en 30 días

• Semana 1: elige Argo CD o Flux. Acuerda la estructura de repositorios y la estrategia de secretos. Habilita acceso de solo lectura para observadores.
• Semana 2: incorpora uno o dos servicios no críticos. Conecta comprobaciones de salud. Añade labels con el SHA del commit.
• Semana 3: activa autosync en desarrollo/staging. Mantén sincronización manual y aprobaciones en producción.
• Semana 4: migra producción. Mide lead time, MTTR y tasa de fallos de cambio. Documenta los ejercicios de rollback.

Conclusión

GitOps no reemplaza CI/CD: lo complementa. CI construye y prueba; GitOps aplica y reconcilia continuamente. Si ejecutas varios servicios o clústeres, GitOps suele aportar rápidamente auditabilidad, seguridad y velocidad. Combínalo con IaC, buena observabilidad y una estrategia razonable para secretos, y tendrás una ruta confiable desde el commit hasta producción.

Si hoy tu entorno es pequeño y sencillo, mantenlo sencillo. Cuando aparezca la complejidad —más equipos, más clústeres— sabrás cuándo recurrir a GitOps.