GitOps: define the delivery contract before choosing the tool
What to establish about versions, review and recovery before adding a controller to your cluster.
GitOps is easier to understand when we start with the delivery problem. We want to know which version should be running, who approved the change and how to return to a known configuration.
The repository as a technical conversation
In the EKS lab design, declarative configuration has a repository separate from application code. An image change becomes a reviewable diff. That separation is a design choice rather than a universal requirement: a small team may organize things differently.
A review should explain what changes and how it will be checked. Valid YAML can still describe an application that cannot start or a memory limit that is too small.
Build and delivery boundaries
The build pipeline produces an identifiable artifact. Configuration records which artifact should be deployed. The controller reconciles that state with the cluster. Separating these responsibilities helps define each component’s permissions.
Operational decisions remain. Data migrations, dependency order and diagnosing degraded applications require additional procedures.
A rollback you can explain
Returning to an earlier configuration is only part of recovery. Before promising automatic rollback, I would test a failing image and document what happens to traffic and data.
The portfolio presents that sequence as a lab plan. The next iteration should provide manifests and a reproducible run. Its value will come from showing the change, failure and recovery, rather than a screenshot of a green dashboard.
GitOps resulta más fácil de entender cuando empezamos por el problema de entrega. Queremos poder responder qué versión debería ejecutarse, quién aprobó el cambio y cómo regresar a una configuración conocida.
El repositorio como conversación técnica
En el diseño del laboratorio EKS, la configuración declarativa tiene un repositorio separado del código de la aplicación. Un cambio de imagen queda visible como una diferencia revisable. Esa separación es una decisión de diseño, no una obligación universal: un equipo pequeño puede organizarlo de otra manera.
La revisión debería explicar qué cambia y cómo se comprobará. Un archivo YAML válido todavía puede describir una aplicación que no arranca o un límite de memoria demasiado pequeño.
Construcción y entrega tienen fronteras
El pipeline de construcción produce un artefacto identificable. La configuración registra cuál se desea desplegar. El controlador reconcilia ese estado con el clúster. Dividir esas responsabilidades ayuda a definir los permisos de cada parte.
Eso no elimina las decisiones operativas. Las migraciones de datos, el orden de dependencias y el diagnóstico de una aplicación degradada requieren procedimientos adicionales.
Un rollback que se pueda explicar
Volver a una configuración anterior es solo una parte de la recuperación. Antes de prometer un rollback automático, probaría una imagen fallida y documentaría qué sucede con el tráfico y los datos.
En el portafolio presento esa secuencia como un plan de laboratorio. La siguiente iteración debe aportar los manifiestos y una ejecución reproducible. El valor no estará en una captura de un panel en verde, sino en poder mostrar el cambio, el fallo y la recuperación.