Módulo 1: Why Cicd And Gitops
4. Qué es GitOps
Descripción
Ya sabes automatizar validaciones (CI) y automatizar despliegues (CD). "GitOps" es un término que vas a escuchar constantemente junto a esos dos, y que casi nunca se explica con precisión: no es una herramienta que se instala, ni un producto que se compra. Es un principio de operación: Git deja de ser solo el historial de tu código y se convierte en la única fuente de verdad de qué infraestructura —y qué código— debería existir en este momento. Esta lección te da el origen exacto del término, la definición precisa del principio, y por qué el pipeline que vas a construir en esta guía es una implementación de GitOps, aunque no se llame así en ningún YAML.
Conexión con el módulo
Con esta lección se cierra toda la teoría fundacional del módulo. Las lecciones 2 y 3 te dieron el problema y el vocabulario de CI/CD; esta lección agrega la pieza conceptual que falta para entender por qué Git, específicamente, es el lugar correcto para que viva esa fuente de verdad, y no una base de datos separada o un documento aparte. La lección 5 cierra la teoría eligiendo la herramienta concreta (GitHub Actions) que va a implementar este principio en el resto de la guía. El Módulo 7 (lección 4) retoma esta lección para distinguir dos formas técnicas distintas de aplicar el mismo principio: push (la que construyes aquí) y pull (la que usa Kubernetes con ArgoCD/Flux).
Analogía: el libro mayor
Imagina una empresa donde, en teoría, existe un inventario: qué productos hay, en qué cantidad, en qué depósito. Pero en la práctica, ese inventario vive de dos formas distintas a la vez: hay un documento escrito que alguien actualiza "cuando se acuerda", y hay lo que cada empleado recuerda haber movido de un depósito a otro sin anotarlo. El día que alguien pregunta "¿cuántas unidades hay realmente?", la respuesta depende de a quién le preguntes — el documento dice una cosa, la memoria de Juan dice otra, y nadie puede afirmar con certeza cuál de las dos versiones es la real.
GitOps es la decisión de que existe un solo libro mayor, y ese libro es Git. No "el documento y también lo que la gente recuerda" — solo el documento, versionado, con historial completo de quién escribió qué y cuándo. Si algo no está en Git, no cuenta como parte de la verdad, sin importar qué tan seguro esté alguien de haberlo hecho. Y si algo en la infraestructura real no coincide con lo que dice Git, eso no es "una segunda versión válida" — es drift: un error que hay que corregir, no una fuente alternativa de verdad.
El origen exacto del término
GitOps no es un concepto que exista "desde siempre" en la industria de infraestructura — tiene un origen datado, con un nombre y una fecha concretos:
EL ORIGEN DE GitOps
ago-2017 Alexis Richardson, CEO de Weaveworks, acuña el término
"GitOps" en una serie de publicaciones del blog oficial
de la empresa, describiendo cómo Weaveworks operaba
Kubernetes usando Git como mecanismo central de despliegue
│
2017-2018 El término se adopta rápidamente en la comunidad de
Kubernetes — coincide con la maduración de operadores
como Flux (creado por la propia Weaveworks)
│
2020 La Cloud Native Computing Foundation (CNCF) acepta a Flux
como proyecto — GitOps deja de ser terminología de una
sola empresa y se vuelve vocabulario estándar del
ecosistema cloud native
│
hoy GitOps se usa para describir tanto el patrón pull-based
original de Kubernetes (ArgoCD, Flux) como el patrón
push-based de un pipeline de CI que aplica infraestructura
— el mismo principio, dos mecanismos técnicos distintos
(retomado en el Módulo 7 de esta guía)El dato que vale la pena que te lleves de esta línea de tiempo: GitOps nació específicamente en el contexto de Kubernetes, no de Terraform ni de infraestructura en general. Que esta guía lo aplique a un pipeline de Terraform es una extensión legítima y ampliamente adoptada del mismo principio —no una desviación del término—, pero es importante que sepas de dónde viene, porque te va a ayudar a entender por qué, cuando alguien menciona "GitOps" en una entrevista o una oferta de trabajo, con frecuencia está pensando primero en ArgoCD o Flux, no en un apply.yml de GitHub Actions.
El principio, con precisión (no la herramienta)
GitOps se define, de forma estándar en la industria, por cuatro propiedades — vale la pena que las tengas exactas, porque son las que determinan si algo "es GitOps" o simplemente "usa Git":
- El estado deseado se declara. No hay una lista de comandos a ejecutar en orden — hay una descripción de qué debería existir. Esto ya lo aprendiste, con otro nombre, en
terraform-and-iac-guide(lección 3): es la misma idea de "declarativo vs. imperativo". - Git es la única fuente de verdad. El estado deseado vive versionado en un repositorio Git — no en la cabeza de nadie, no en un documento aparte, no en la consola donde alguien hizo un cambio "rápido, solo por esta vez".
- Los cambios aprobados se aplican automáticamente. Un sistema —no un humano tecleando comandos— es responsable de hacer que la infraestructura real coincida con lo que Git dice. El humano decide qué cambio aprobar (vía pull request); el sistema decide cómo aplicarlo.
- El estado real se reconcilia continuamente contra Git. No basta con aplicar una vez — el sistema debe poder detectar cuándo la realidad se desvía de lo declarado (drift) y, según el diseño, corregirlo automáticamente o al menos alertarlo. Esta guía construye la versión de detección (Módulo 5,
drift.yml); la corrección automática completa queda fuera de su alcance.
Fíjate en algo importante: ninguna de estas cuatro propiedades menciona una herramienta específica. GitOps no es "usar ArgoCD" ni "usar GitHub Actions" — es cumplir estas cuatro propiedades, sin importar qué herramienta lo implemente. Podrías, en teoría, implementar un sistema GitOps rudimentario con un cron job que hace git pull && terraform apply cada cinco minutos — sería tosco, sin revisión ni gates, pero técnicamente cumpliría las cuatro propiedades. Lo que esta guía construye, con GitHub Actions y act, es una versión mucho más robusta y segura del mismo principio, no una implementación distinta de otro principio.
Por qué el pipeline de esta guía es GitOps, aunque no diga "GitOps" en ningún YAML
Repasa lo que vas a construir, módulo por módulo, contra las cuatro propiedades de arriba:
| Propiedad de GitOps | Cómo la cumple el pipeline de esta guía |
|---|---|
| Estado deseado, declarado | El HCL de andes-cargo-infra/, heredado íntegro de terraform-and-iac-guide |
| Git como única fuente de verdad | Todo cambio de infraestructura entra por un commit en una rama, revisado en un Pull Request — nunca por un clic directo en una consola |
| Aplicación automática de cambios aprobados | apply.yml (Módulo 5), disparado por push a main, sin que nadie teclee terraform apply |
| Reconciliación continua contra Git | drift.yml (Módulo 5), un terraform plan programado que detecta si la realidad se desvió de lo declarado |
Esto es, con precisión, GitOps de infraestructura. La diferencia con el GitOps "clásico" de Kubernetes —el que vas a nombrar, sin construir, en el Módulo 7— no está en el principio: está en el mecanismo que aplica el cambio. Aquí, un pipeline de CI (GitHub Actions) empuja el cambio hacia afuera cuando detecta un push a main — esto se llama push-based. En el modelo de Kubernetes con ArgoCD o Flux, un operador que corre dentro del clúster observa el repositorio Git constantemente y jala los cambios hacia adentro cuando los detecta — esto se llama pull-based. Son dos mecanismos técnicos genuinamente distintos, que hasta tienen implicaciones de seguridad diferentes (en pull, nadie externo necesita credenciales para escribir en el clúster; en push, el pipeline sí necesita credenciales para escribir hacia afuera) — pero ambos cumplen las cuatro propiedades de GitOps. El Módulo 7 (lección 4) retoma esta distinción con el detalle técnico completo.
Errores comunes
Creer que "GitOps" significa "tener el código en GitHub" (el más común, por lejos). Qué pasa: alguien concluye que, como su equipo ya versiona el HCL en un repositorio, ya está "haciendo GitOps". Por qué pasa: el nombre incluye la palabra "Git", y usar control de versiones es, sin dudas, un prerequisito. Cómo detectarlo: si tu infraestructura se versiona en Git, pero alguien todavía puede aplicar un cambio corriendo terraform apply a mano, sin pasar por un Pull Request revisado. Cómo corregirlo: versionar el código es la propiedad #2, pero no la única — sin aplicación automática de cambios aprobados (#3) y reconciliación continua (#4), tienes control de versiones, no GitOps. Las cuatro propiedades tienen que cumplirse juntas.
Pensar que GitOps es exclusivo de Kubernetes (de alcance, corregido en esta lección). Qué pasa: alguien, sabiendo que el término nació en el contexto de Kubernetes, concluye que aplicarlo a un pipeline de Terraform "no es GitOps de verdad", sino una apropiación incorrecta del término. Por qué pasa: el origen histórico (Weaveworks, 2017, Kubernetes) es real y específico. Cómo detectarlo: si crees que el pipeline de esta guía debería llamarse de otra forma. Cómo corregirlo: el origen del término no limita su alcance — las cuatro propiedades que lo definen (declarativo, Git como fuente de verdad, aplicación automática, reconciliación) no mencionan Kubernetes en absoluto, y la extensión a infraestructura general (Terraform, CloudFormation, cualquier IaC) es ampliamente aceptada en la industria hoy. Lo que sí varía, y vale la pena distinguir con precisión (Módulo 7), es el mecanismo: push aquí, pull en Kubernetes.
Confundir "el sistema aplica automáticamente" con "nadie revisa nada" (conceptual, ya visto en la lección 3). Qué pasa: alguien interpreta la propiedad #3 ("los cambios aprobados se aplican automáticamente") como si significara que no hay ningún control humano en el proceso. Por qué pasa: la palabra "automáticamente" suena, a primera lectura, a "sin supervisión". Cómo detectarlo: si crees que GitOps elimina la revisión humana en vez de reubicarla. Cómo corregirlo: la palabra clave de la propiedad #3 es "aprobados" — el humano sigue decidiendo qué cambio aprobar, vía Pull Request, exactamente como viste en la lección 3 de este módulo. Lo que GitOps automatiza es el paso mecánico de "hacer que la infraestructura coincida con lo aprobado", no la decisión de qué aprobar.
Ejercicios
Ejercicio 1 — Evalúa un escenario contra las cuatro propiedades. Un equipo describe su proceso así: "todo nuestro Terraform vive en un repositorio de GitHub, y cuando alguien quiere cambiar algo, abre un Pull Request que otra persona revisa. Una vez aprobado, la persona que lo aprobó corre terraform apply desde su propia laptop". ¿Cuáles de las cuatro propiedades de GitOps cumple este equipo, y cuál no?
Ver solución
Cumple: (1) estado declarado (es Terraform, declarativo por diseño) y (2) Git como fuente de verdad con revisión vía PR. No cumple (3): la aplicación del cambio sigue siendo un humano tecleando terraform apply a mano, no un sistema automático — esto reintroduce exactamente el problema #1 de la lección 2 de este módulo (quién corrió el apply, con qué credenciales). Tampoco cumple, casi con certeza, (4): sin un job programado de detección de drift, no hay reconciliación continua. Este equipo tiene "IaC con revisión de código" — un paso real de madurez sobre el apply sin ningún proceso — pero todavía no GitOps completo.
Ejercicio 2 — Distingue origen de alcance. Explica a un colega, en dos o tres frases, por qué es correcto decir que el pipeline de Andes Cargo "hace GitOps" aunque el término haya nacido específicamente para describir cómo Weaveworks operaba Kubernetes en 2017.
Ver solución
Una respuesta completa suena, más o menos, así: "GitOps no se define por la tecnología a la que se aplica, sino por cuatro propiedades: infraestructura declarada, Git como única fuente de verdad, aplicación automática de cambios aprobados, y reconciliación continua contra lo real. El pipeline de Andes Cargo cumple las cuatro, aunque aplique a Terraform y no a Kubernetes — el origen histórico del término explica de dónde viene el nombre, no dónde termina su alcance válido. Lo que sí cambia entre el caso original de Kubernetes y el de esta guía es el mecanismo técnico —pull vs. push—, no si califica o no como GitOps."
Ejercicio 3 — Diagnostica el drift sin usar la palabra "drift". Explica a alguien que nunca escuchó el término qué significa la cuarta propiedad de GitOps (reconciliación continua), usando el ejemplo de la política del bucket andes-cargo-shipment-docs que alguien pudo haber cambiado manualmente en la consola.
Ver solución
Una explicación completa suena, más o menos, así: "Aunque todo el proceso de cambios pase por Git y por revisión, alguien siempre podría, técnicamente, entrar a la consola de AWS y cambiar algo directamente, sin pasar por ningún Pull Request. Un sistema que solo aplica cambios cuando Git cambia, pero nunca vuelve a comparar lo real contra lo declarado, no se enteraría de ese cambio directo — quedaría invisible hasta que alguien lo note por accidente. La cuarta propiedad de GitOps es la garantía de que, periódicamente, alguien —un job automático, en este caso— vuelve a preguntar 'lo que existe de verdad, ¿sigue coincidiendo con lo que Git dice que debería existir?', y avisa si la respuesta es no."
Resumen y siguiente paso
En esta lección conociste el origen exacto de GitOps (Alexis Richardson, Weaveworks, agosto de 2017, en el contexto de Kubernetes) y las cuatro propiedades que lo definen con precisión: estado declarado, Git como única fuente de verdad, aplicación automática de cambios aprobados, y reconciliación continua contra la realidad. Confirmaste que el pipeline que vas a construir en esta guía cumple las cuatro, aunque use Terraform en vez de Kubernetes, y aunque no diga "GitOps" en ningún archivo YAML. También adelantaste la distinción entre GitOps push-based (esta guía) y pull-based (Kubernetes con ArgoCD/Flux), que el Módulo 7 retoma con el detalle técnico completo.
Antes de avanzar deberías poder: nombrar las cuatro propiedades de GitOps sin ayuda; explicar por qué "tener el código en GitHub" no es, por sí solo, GitOps; y ubicar, en el pipeline de esta guía, qué pieza corresponde a cada una de las cuatro propiedades.
Con esto se cierra toda la teoría fundacional del módulo. La lección 5 elige, con evidencia de mercado honesta, la herramienta concreta que va a implementar todo esto: GitHub Actions — nombrando también sus alternativas reales, sin pretender que "gana" en todas partes.
Recursos
- Weaveworks Blog — What Is GitOps, Really? — el origen del término, escrito desde la propia Weaveworks, base histórica de esta lección.
- GitHub Docs — About continuous deployment — el vocabulario de aplicación automática de cambios, usado en la propiedad #3 de esta lección.
- CNCF — Flux — el proyecto GitOps original de Weaveworks, hoy graduado en la Cloud Native Computing Foundation, nombrado (no construido) en el Módulo 7 de esta guía.
terraform-and-iac-guide, Módulo 1, lección 3 (03-what-is-infrastructure-as-code.md) — la definición de "declarativo" que sostiene la propiedad #1 de GitOps, ya asumida en esta lección.