GitOps: cuando tu repositorio manda en producción

⏱ Tiempo de lectura estimado: 7 minutos

¿Alguna vez alguien en tu equipo hizo un cambio en producción directamente desde su terminal, sin PR, sin revisión, sin nada, y tres días después nadie recordaba qué había cambiado ni por qué? Sí. Todos hemos estado ahí. Ese momento incómodo en el que miras los logs y preguntas «¿quién tocó esto?» y el silencio responde por todos.

GitOps nació, en parte, para que eso no vuelva a pasar. La idea es tan simple que da un poco de rabia no haberla pensado antes: tu repositorio de Git es la única fuente de verdad para el estado de tu infraestructura. Si no está en Git, no existe. Si quieres cambiar algo en producción, haces un commit. El sistema se encarga del resto.

Dicho esto, GitOps no es magia ni un producto que instalas y listo. Es una forma de trabajar, y como toda forma de trabajar, tiene sus matices.

GitOps no es solo "infraestructura como código con esteroides"

Mucha gente confunde GitOps con tener tus manifiestos de Kubernetes en un repo. Eso es infraestructura como código, sí, pero no es GitOps por sí solo.

La diferencia está en quién o qué aplica los cambios. En un flujo tradicional, tu pipeline de CI/CD empuja cambios al clúster: el pipeline tiene credenciales, tiene acceso, ejecuta kubectl apply y reza para que todo salga bien. En GitOps, el modelo se invierte. Hay un agente corriendo dentro del clúster, mirando el repositorio constantemente, y cuando detecta una diferencia entre lo que Git dice que debería existir y lo que realmente existe, lo corrige.

Eso cambia bastante las cosas. Ya no necesitas dar acceso de escritura a tu pipeline sobre el clúster. El clúster se gestiona a sí mismo, reconciliando su estado real con el estado deseado que vive en Git.

Las herramientas más usadas para esto son Argo CD y Flux CD. Las dos hacen esencialmente lo mismo, con diferencias de filosofía y UX que da para otro artículo.

El bucle de reconciliación: el corazón del modelo

El concepto clave en GitOps es la reconciliación continua. Imagina que alguien (o algo) entra al clúster y borra un deployment manualmente. En un mundo sin GitOps, ese cambio se queda. En un mundo GitOps, el agente lo detecta en segundos y lo restaura, porque Git dice que ese deployment debe existir.

Esto tiene una implicación enorme: los cambios manuales en producción dejan de tener sentido. Si haces un kubectl delete directo y el agente lo revierte en 30 segundos, aprendes rápido que el único camino es el repositorio.

En mi experiencia, esto genera fricción al principio. A la gente le cuesta soltar el control directo. Hay una sensación de «pero yo sé lo que estoy haciendo, ¿por qué tengo que hacer un PR para cambiar una variable de entorno?». La respuesta corta: porque dentro de tres meses, cuando eso rompa algo, vas a querer saber quién lo cambió y por qué.

Cómo estructurar tu repositorio para no arrepentirte después

Aquí es donde la mayoría mete la pata al arrancar. GitOps funciona con cualquier estructura de repo, pero no todas las estructuras sobreviven al crecimiento del equipo.

Un repo por entorno vs. un repo con ramas por entorno

Hay dos patrones comunes. El primero es tener un único repositorio con directorios separados para cada entorno: environments/dev, environments/staging, environments/prod. El segundo es usar ramas: main para producción, staging para staging, etc.

El patrón de directorios gana casi siempre. Las ramas divergen, los merges se complican, y terminas con configuraciones que son difíciles de comparar entre entornos. Con directorios, puedes ver en un solo vistazo qué hay en prod y qué hay en staging sin cambiar de rama.

Ojo que esto no significa que todo tiene que vivir en el mismo repositorio. Hay equipos que separan el repo de aplicación del repo de infraestructura, y tiene sentido cuando el equipo de plataforma y el equipo de producto son diferentes. Lo que no recomiendo es mezclar el código de tu app con los manifiestos de Kubernetes en el mismo árbol sin una separación clara. Eso se convierte en un caos más rápido de lo que imaginas.

Usa Kustomize o Helm, pero elige uno y comprométete

Argo CD y Flux soportan tanto Kustomize como Helm nativamente. Kustomize es más simple y tiene menos magia: defines una base y aplicas overlays por entorno. Helm es más potente pero introduce templates que pueden volverse ilegibles si no tienes disciplina.

Algo que me ha funcionado: Kustomize para infraestructura propia (deployments, services, configmaps) y Helm para dependencias externas como cert-manager, ingress-nginx o monitoring stacks. Lo mejor de los dos mundos sin mezclar filosofías donde no toca.

El flujo completo en la práctica: de un commit a producción

Para que quede concreto, así es como se ve un flujo GitOps real:

El desarrollador abre un PR que actualiza la imagen de un servicio en el manifiesto de Kubernetes. El PR pasa por revisión de código, igual que cualquier cambio de aplicación. Se aprueba y se mergea a main. El agente (Argo CD, en este caso) detecta el cambio en el repo en cuestión de minutos, calcula la diferencia entre el estado actual del clúster y el estado deseado, y aplica el cambio. En el dashboard de Argo CD puedes ver en tiempo real cómo el deployment se actualiza, los pods nuevos arrancan y los viejos terminan.

Si algo sale mal, el rollback es un git revert. No hay scripts especiales, no hay procedimientos de emergencia complicados. El repositorio vuelve al estado anterior y el agente lo reconcilia.

Eso, para equipos que han vivido rollbacks manuales a las 2 de la mañana, es un cambio de vida.

Lo que GitOps no resuelve (para que no te lleves sorpresas)

GitOps no reemplaza el monitoreo. Si tu app tiene un bug lógico que no rompe el deployment pero sí rompe la experiencia del usuario, el agente no lo va a detectar. Sigues necesitando Prometheus, Grafana, alertas bien configuradas y alguien que las mire.

Tampoco resuelve la gestión de secretos. No metas credenciales en Git, ni cifradas ni sin cifrar. Para eso existen herramientas como Sealed Secrets, External Secrets Operator o Vault de HashiCorp. GitOps y gestión de secretos son problemas separados que se complementan, no el mismo problema.

Y por último: GitOps no es un sustituto de tener buenas prácticas de desarrollo. Un repositorio mal organizado sigue siendo un repositorio mal organizado, aunque tenga Argo CD mirándolo.

Antes de irte

Si llevas tiempo queriendo adoptar GitOps pero sientes que tu infraestructura actual está demasiado desordenada para empezar, entiendo esa sensación. Migrar hacia un modelo declarativo cuando tienes años de cambios manuales acumulados no es trivial, y nadie te va a decir que lo es. El truco está en no intentar migrar todo a la vez.

Empieza por un entorno, un servicio, un agente. Lo que funciona ahí lo replicas. Lo que no funciona, lo ajustas antes de escalar. Así es como se adopta cualquier cosa que valga la pena.

Temas relacionados donde podrías profundizar: