La deriva es el enemigo que GitOps vino a nombrar

Cómo se pudren los entornos

Nadie decide hacer única la producción. Ocurre una emergencia a la vez: un hotfix aplicado a mano a las 2am, un ajuste de configuración durante un incidente, un límite de recursos subido para callar una alerta. Cada cambio es razonable; su acumulación es un entorno que nadie puede reconstruir.

El costo aflora después, siempre en el peor momento — un ejercicio de recuperación ante desastres que falla, un entorno de staging que deja de predecir producción, una actualización que se comporta distinto en el único clúster que importa.

Reconciliación, no despliegue

Argo CD suele presentarse como herramienta de despliegue, pero su valor duradero es la disciplina que OpenGitOps enuncia como principios: estado deseado expresado declarativamente, versionado e inmutable, extraído automáticamente, reconciliado continuamente. En el vocabulario del propio Argo CD, el target state vive en Git, el controlador lo compara continuamente con el live state, y una aplicación cuyo estado vivo se desvía queda marcada OutOfSync — la deriva se vuelve una condición visible y alertable en lugar de una sorpresa latente. Con automated sync policy, self-heal y pruning activados, el controlador no solo informa la divergencia: la revierte.

Eso replantea el hotfix de las 2am. El arreglo sigue ocurriendo — pero aterriza como commit, o aparece como deriva a la mañana siguiente con un nombre adjunto. En ambos casos la historia del entorno sigue siendo verdadera.

La política pertenece al mismo bucle

Declarado el estado deseado, la política como código controla qué puede declararse: admission controllers — OPA Gatekeeper o Kyverno — aplican líneas base de seguridad y estándares de recursos en la puerta del clúster, mientras las comprobaciones de SBOM y procedencia al estilo sigstore y SLSA corren en el merge, donde los cambios son baratos de corregir, no en el release, donde son caros de discutir. Rápido porque es seguro, no a pesar de serlo.