Qué es GitOps y por qué tu equipo debería adoptarlo

GitOps es una de esas palabras que se usan mucho y se explican poco. Si preguntás a tres personas qué es, probablemente recibas tres definiciones distintas. Acá va la mía, en una línea:

GitOps es operar tu infraestructura y tus aplicaciones usando Git como única fuente de verdad declarada, con un proceso automático que reconcilia el estado real del sistema con el estado deseado del repo.

Traducción: vos declarás cómo querés que se vea todo en Git, y el sistema se encarga de que sea así, siempre. Si alguien cambia algo a mano en el cluster, el sistema lo revierte. Si alguien mergea un cambio al repo, el sistema lo aplica.

Los 4 principios de GitOps

La CNCF define GitOps con cuatro principios. Son cortos, pero cada uno tiene implicancias profundas:

1. Estado deseado declarativo. Toda la configuración (apps, infra, policies) está descrita de forma declarativa, versionada en Git.
2. El estado deseado se captura de forma inmutable. Nada de “config que cambia sola”: el repo es la verdad, con versión, autor y timestamp de cada cambio.
3. Agentes de software recuperan el estado deseado. Un operador (Argo CD, Flux) corre en el cluster, lee el repo y aplica lo que falta, constantemente.
4. Cierre del loop: convergencia continua y auto-reparación. El agente detecta drift (desvíos entre lo real y lo deseado) y lo corrige solo.

El loop, en la práctica

Un cluster con GitOps funciona así, en loop infinito:

 git push (cambio en el repo)
        │
        ▼
  ┌─ agente GitOps (Argo CD / Flux) ─┐
  │  1. detecta el nuevo estado      │
  │  2. compara con lo que hay       │
  │  3. aplica el diff               │
  │  4. reporta el estado            │
  └───────────────┬──────────────────┘
                  │
        git pull (si alguien toca el cluster a mano,
                  el drift se revierte automáticamente)

No hay kubectl apply manual, no hay “a mí me funciona en mi máquina”, no hay “¿quién tocó el cluster?”. Cada cambio queda registrado como un commit, con su PR, su review y su CI detrás.

Beneficios que se notan desde el día uno

• Trazabilidad total: quién cambió qué, cuándo y por qué. Todo es un commit.
• Rollbacks instantáneos: revertí un commit y el cluster vuelve al estado anterior. Listo.
• Auto-healing: alguien borró un pod o modificó un deployment a mano → el agente lo restaura.
• Auditoría gratis: el historial de Git ES el audit log.
• Review de cambios como código: PRs, approvals, CI — el mismo flujo que ya usás para código.

Los mitos que escuchás por ahí

“GitOps es solo Argo CD.” No. Argo CD y Flux son las herramientas más conocidas, pero GitOps es una práctica (los 4 principios de arriba). Se puede hacer GitOps hasta con un CronJob y kubectl apply — aunque no te lo recomiendo.

“GitOps elimina a los DevOps.” Al contrario: automatiza lo repetitivo para que el equipo se dedique a lo difícil (arquitectura, políticas, seguridad).

“GitOps es solo para Kubernetes.” Es donde más se usa y donde las herramientas maduraron, pero el patrón aplica a cualquier sistema declarativo: Terraform, config de red, DNS, etc.

¿Y ahora?

Si esto te resonó, el siguiente paso lógico es elegir herramienta y armar los patrones de repositorio. Comparé las dos opciones principales acá:

→ Argo CD vs Flux: cuál elegir para GitOps en 2026

Y si querés el camino completo — de los fundamentos a los anti-patrones de producción, con laboratorios paso a paso — está todo en mi ebook:

→ GitOps para DevOps · 20 capítulos, 6 laboratorios y 118 páginas para gobernar tus clusters con Git.