Toda la infraestructura y aplicaciones:
Esto alinea la operación con buenas prácticas profesionales de control del cambio.
Pero… ¿qué es exactamente Git en este contexto?
Git es un sistema de control de versiones distribuido.
Sirve para guardar una colección de archivos (código, manifiestos, documentación…) y registrar su evolución en el tiempo de forma estructurada.
Una forma sencilla de entenderlo:
👉 Cada vez que hacemos un commit, estamos creando una foto fija del estado completo del proyecto en ese momento.
No es solo “guardar un archivo”.
Es guardar el estado coherente de todo el conjunto.
Eso nos permite:
En Kubernetes, los manifiestos son:
Aunque no sean un programa tradicional, describen el comportamiento del sistema.
Por eso se consideran Infrastructure as Code (IaC).
Los manifiestos son código porque:
La infraestructura deja de ser algo manual y pasa a ser algo reproducible.
Una foto fija del proyecto en un momento concreto.
Cada commit tiene:
Una línea paralela de desarrollo.
Permite:
La rama principal suele llamarse main o master.
Unir los cambios de una rama a otra.
Esto permite integrar mejoras de forma controlada.
Git es distribuido.
Eso significa que:
Flujo típico de trabajo:
El servidor remoto permite:
A esa colección de archivos versionados la llamamos:
👉 Repositorio (repo)
En nuestro caso, el servidor Git está dentro de nuestra propia infraestructura:
git.c2et.com
Esto nos da:
En entornos públicos es habitual usar plataformas como:
Pero el concepto es exactamente el mismo.
Porque ahora:
Esto convierte la infraestructura en algo:
No estamos improvisando cambios.
Estamos gestionando la evolución controlada del sistema.
Este enfoque no es casual.
Estamos aplicando principios alineados con los modelos de gestión de servicios como ITIL:
Git nos proporciona la base técnica para ello.
Más adelante, formalizaremos completamente este modelo mediante GitOps, donde:
En ese punto, el control del cambio dejará de ser solo una buena práctica y pasará a ser una garantía técnica del sistema.