La mayoría de las organizaciones descubren GitOps por el lado técnico, como una forma más cómoda de desplegar en Kubernetes. Pero el argumento que convence a dirección es otro, y es de gobierno: la capacidad de responder con precisión a la pregunta de quién cambió qué en producción, cuándo, con qué aprobación y cómo se revierte.
El problema real que resuelve
En un modelo de despliegue convencional, el estado de producción es el resultado acumulado de todo lo que se ha ejecutado contra ella: pipelines, comandos manuales de una madrugada complicada, ajustes hechos desde una consola web. Nadie tiene la foto completa, y reconstruirla ante una auditoría es un ejercicio arqueológico.
GitOps invierte el planteamiento: el estado deseado del sistema vive declarado en un repositorio, y un agente se encarga de que la realidad coincida con lo declarado. El repositorio deja de ser documentación y pasa a ser la fuente de verdad.
Lo que gana quien tiene que responder por el sistema
- Trazabilidad completa sin esfuerzo adicional. Cada cambio en producción es un commit con autor, fecha, revisor y motivo. El registro de auditoría no hay que construirlo: es un efecto secundario de trabajar así.
- Separación real de funciones. Quien propone un cambio no es quien lo aprueba, y eso queda impuesto por el propio flujo de trabajo en vez de por una política que alguien debe recordar cumplir.
- Vuelta atrás en un paso conocido. Revertir es revertir un commit. No depende de que alguien recuerde qué había antes.
- Detección de deriva. Si alguien toca producción por fuera, el sistema lo detecta y lo revierte o lo notifica. Ese cambio manual que nadie documentó deja de ser posible en silencio.
Para organizaciones con obligaciones de cumplimiento, este último punto suele ser el que cierra la decisión: convierte una política escrita en un control técnico verificable.
Qué cambia para el equipo
Menos de lo que se teme, pero no cero. El cambio principal es que ya no se despliega ejecutando algo contra el clúster, sino modificando una declaración y aprobándola. Para el trabajo diario supone un paso más; a cambio, desaparece la categoría entera de incidencias causadas por diferencias entre entornos.
La resistencia habitual aparece en las urgencias: cuando algo arde, el instinto es entrar y arreglarlo a mano. Conviene definir de antemano un procedimiento de emergencia explícito, con su registro correspondiente, en lugar de fingir que nunca hará falta. Un procedimiento de excepción documentado se audita; uno improvisado, no.
Dónde falla en la práctica
Los secretos. Es el primer obstáculo y el que más implantaciones descarrila. Las credenciales no pueden vivir en el repositorio, así que hay que resolverlo con cifrado o con un gestor externo antes de empezar, no sobre la marcha.
Un único repositorio para todo. Mezclar el código de las aplicaciones con las declaraciones de infraestructura parece cómodo al principio y acaba generando permisos imposibles de razonar. Separarlos desde el día uno cuesta poco; separarlos después, mucho.
Aprobaciones que no aprueba nadie. Si las revisiones se convierten en un sello automático, se ha añadido burocracia sin ganar control. El valor está en que alguien mire de verdad, y eso exige que los cambios sean pequeños y legibles.
Cuándo no compensa
Con un único servicio, un entorno y dos personas que despliegan, GitOps añade ceremonia sin resolver nada: no hay problema de trazabilidad que merezca esa inversión. El punto en el que empieza a rentar es cuando hay varios entornos, varios equipos tocando lo mismo, o alguna obligación externa de demostrar control sobre los cambios.
¿Necesitáis demostrar control sobre lo que llega a producción? Hablemos de vuestro flujo de despliegue →
Sigue leyendo
- Seguridad en el pipeline sin frenar al equipo
- Un pipeline de CI/CD en GitHub Actions listo para producción
Puedes ver todo lo que hacemos en servicios, o echar un vistazo a los tipos de proyecto que solemos abordar.