Esta lección cierra una promesa que el curso lleva arrastrando desde el módulo 7. En la lección 07-06 trazamos una frontera explícita: allí hablábamos de integración continua —comprobar automáticamente que lo que se integra funciona— y dejamos para aquí cómo ese código llega a los usuarios. En la 07-04 aplazamos la mecánica de los entornos y la promoción. Y en la 05-05, al crear la etiqueta anotada v1.4.0, dijimos que las etiquetas serían la pieza que dispara un despliegue.

Todo converge aquí.

El cambio de perspectiva es grande. Hasta ahora, Git ha sido una herramienta que usan personas: Ana escribe código, Bruno revisa, Carla integra. A partir de este punto, Git es también —y sobre todo— una herramienta que usan máquinas. Tuberías que clonan, leen etiquetas, comparan hashes, construyen artefactos y publican en producción sin que nadie pulse nada. En una organización con despliegue continuo, la inmensa mayoría de los git clone del día los ejecuta un servidor, no una persona.

Y eso cambia el peso de cada operación. Cuando git push origin main significa "esto estará en producción dentro de cuatro minutos", el rigor deja de ser una virtud profesional y pasa a ser un requisito operativo.

1. Git como fuente única de verdad
2. Integración, entrega y despliegue continuos
3. Qué dispara un despliegue y cómo se ata a Git
4. El artefacto se identifica por el hash del commit
5. Infraestructura como código
6. GitOps: el repositorio como estado deseado
7. Secretos en un mundo automatizado
8. Versionado y changelog automáticos
9. Reversión en producción
10. Que la tubería no dependa de un humano

La idea de fondo de DevOps, en lo que respecta a Git, es una ampliación de lo que ya sabes: el repositorio deja de contener solo código.

Históricamente, un repositorio contenía la aplicación. Todo lo demás —cómo se configura el servidor, qué versión de la base de datos hay, qué variables de entorno existen, cómo se despliega— vivía en la cabeza de alguien, en un documento, en una consola web o en un guion en el escritorio de un administrador.

El cambio consiste en meter todo eso también en Git:

Esa última fila es la más valiosa y la que más se subestima. Si app.js empieza a necesitar una variable de entorno nueva, el commit que introduce el código y el que declara la variable son el mismo commit. Nunca existe una revisión del repositorio donde el código pida algo que la configuración no da.

Si algo puede romper producción, debe estar en Git.

Configuración, infraestructura, migraciones de base de datos, definición de las tuberías, políticas de acceso. Todo lo que sea un fichero de texto y afecte al comportamiento del sistema.

Y el corolario, que es igual de importante:

Si algo está en Git, no debe cambiarse fuera de Git.

Modificar la configuración de producción desde una consola web crea una deriva: el repositorio dice una cosa y la realidad dice otra. En cuanto la deriva existe, el repositorio deja de ser la fuente de verdad y todo el edificio se cae. Es el problema que GitOps ataca directamente (apartado 6).

Con una excepción absoluta, ya establecida en la lección 08-05: los secretos, nunca. Contraseñas, claves de API, certificados privados, tokens. Van en un gestor de secretos y se inyectan en el momento del despliegue. Volveremos sobre ello en el apartado 7.

Tres términos que se confunden constantemente, y cuya diferencia es exactamente dónde está el botón humano.

La diferencia entre entrega y despliegue es exactamente un clic. Y la decisión de quitar ese clic no es técnica sino de confianza: se quita cuando el conjunto de pruebas es tan bueno y la reversión tan rápida que un humano mirando la pantalla no aporta seguridad, solo latencia.

1. Pruebas en las que se confía de verdad. Si el equipo ejecuta pruebas manuales "por si acaso" antes de desplegar, no está listo.
2. Reversión en minutos. El seguro no es "no fallar nunca", sino "arreglarlo antes de que importe".
3. Despliegue progresivo. Sacar la versión nueva a un porcentaje del tráfico y observar antes de completar.
4. Observabilidad. Métricas y alertas que detecten un problema antes que los usuarios.
5. Cambios pequeños. Es la conexión con Trunk Based Development (lección 07-05): cuanto más pequeño es el cambio, menor el riesgo y más fácil identificar la causa.

Ese último punto merece énfasis, porque es donde Git y DevOps se tocan directamente. El despliegue continuo obliga a commits pequeños y bien acotados. Si integras un cambio de 2.000 líneas y producción se rompe, no sabes cuál de las 2.000 fue. Toda la disciplina del módulo 8 —commits atómicos, mensajes que explican el porqué, historial legible— pasa de ser una buena práctica a ser una herramienta de operación.

Hay tres mecanismos, y conviene entender qué modelo mental implica cada uno.

Modelo mental: "la rama main es lo que hay en preproducción". La rama deja de ser solo una línea de desarrollo y pasa a ser el puntero a un entorno.

Es el mecanismo natural para entornos no productivos. Cada integración en main actualiza preproducción, sin ceremonia.

Aquí se cierra lo que prometimos en la lección 05-05.

Modelo mental: "la etiqueta v1.4.0 es una versión publicable, y publicarla es desplegarla".

Tres detalles que importan mucho:

1. Se exige etiqueta anotada, no ligera. Recuerda de la lección 05-05 que una etiqueta ligera es solo una referencia a un commit, mientras que una anotada es un objeto propio con autor, fecha, mensaje y posibilidad de firma. Para producción, eso es exactamente lo que quieres: un registro de quién declaró esa versión y cuándo. La comprobación git cat-file -t devuelve tag para las anotadas y commit para las ligeras.

2. Se verifica la firma. git tag --verify comprueba la firma GPG (lección 08-05). Así, crear una etiqueta de producción requiere una clave privada, no solo permisos de escritura.

3. Se comprueba que la etiqueta está en main. git merge-base --is-ancestor impide desplegar una etiqueta puesta sobre una rama que nunca se integró. Es una salvaguarda contra el error de etiquetar desde la rama equivocada, que ocurre más de lo que parece.

Muy importante: el paso de despliegue no reconstruye nada. Recupera el artefacto que ya se construyó cuando ese commit entró en main. Volveremos sobre esto en el apartado siguiente, porque es una de las reglas de oro de la entrega.

Modelo mental: "cualquier commit de main es candidato; alguien decide cuál y cuándo".

Es el mecanismo más flexible y el que hace falta para volver atrás rápido, como veremos en el apartado 9.

Los tres mecanismos combinados, cada uno en su sitio:

Esta es probablemente la práctica más importante de toda la lección, y la que más equipos hacen mal.

Cada artefacto construido —imagen de contenedor, paquete, binario— se etiqueta con el hash completo del commit del que salió.

El hash es el identificador canónico; v1.4.0 y main son alias legibles que apuntan a él. Exactamente la misma relación que en Git entre un hash de commit y las referencias que lo apuntan (lección 03-01): las etiquetas se mueven, el hash no.

1. Elimina la ambigüedad. gestor-tareas:latest no significa nada: es una etiqueta móvil que apunta a lo último que alguien construyó. gestor-tareas:4f8a2e6c9d3b... identifica un contenido exacto y reproducible.

2. Da trazabilidad completa. Ante un error en producción, la cadena se recorre entera y sin preguntar a nadie:

Del contenedor en producción al ticket, en cinco comandos y sin abrir ninguna interfaz.

3. Permite verificar la coherencia. ¿Está desplegado lo que creemos?

4. Hace posible el despliegue idempotente. Desplegar el mismo hash dos veces produce exactamente el mismo resultado. Con latest, no hay forma de saberlo.

El artefacto se construye UNA sola vez y ese mismo artefacto recorre todos los entornos.

Si cada entorno reconstruye el artefacto, lo que has probado no es lo que despliegas. Entre una construcción y otra pueden cambiar las versiones de las dependencias, la imagen base o la versión del compilador. El artefacto que pasó las pruebas y el que llega a producción serían dos cosas distintas, y toda la validación previa deja de significar nada.

Lo que sí cambia entre entornos es la configuración, que se inyecta en el momento del despliegue: variables de entorno, secretos, direcciones de servicios. El artefacto es el mismo binario; el entorno lo parametriza.

Conviene que el propio artefacto sepa de dónde vino:

Ese git describe --tags --always --dirty es una joya para esto. Produce cadenas como:

Ese sufijo -dirty es una alarma valiosa. Un artefacto marcado como dirty se construyó desde una copia de trabajo sucia, lo que significa que no es reproducible desde el repositorio. La tubería debería rechazarlo:

Y en la aplicación, exponer esa información:

Un punto de acceso /version que dice el hash exacto que se está ejecutando resuelve por sí solo la pregunta más frecuente durante una incidencia: "¿qué hay realmente ahí?".

La infraestructura —servidores, redes, bases de datos, balanceadores, permisos— se declara en ficheros de texto versionados, y una herramienta se encarga de que la realidad coincida con lo declarado.

Todo lo que Git sabe hacer con el código se aplica ahora a la infraestructura:

Ese git blame sobre un fichero de infraestructura es una capacidad que hace diez años no existía. La pregunta "¿por qué este servicio tiene 512 MB y no 256?" pasa de ser arqueología a ser un comando.

La práctica estándar consiste en calcular el plan de cambios en la propuesta —para que se pueda revisar— y aplicarlo solo tras la integración:

Publicar el plan en la propuesta es lo que convierte la revisión de infraestructura en algo real: quien revisa no lee un fichero declarativo e imagina el efecto, lee el efecto: "se van a destruir 2 recursos, crear 1 y modificar 3".

Mención aparte, porque es donde el modelo se rompe si no se tiene cuidado. Los ficheros de migración se versionan como todo lo demás:

Pero hay una asimetría fundamental: el código se revierte fácilmente; los datos, no. Un git revert del commit que añadió una columna no devuelve los datos que esa columna contenía.

De ahí la regla de oro de las migraciones, que condiciona cómo se escriben los commits:

Toda migración debe ser compatible hacia atrás durante al menos un despliegue. La versión antigua del código debe seguir funcionando con el esquema nuevo.

En la práctica, eso convierte "renombrar una columna" en una secuencia de tres despliegues:

1. Añadir la columna nueva; el código escribe en ambas y lee de la vieja.
2. Migrar los datos; el código lee de la nueva.
3. Eliminar la columna vieja.

Tres commits, tres despliegues, y en ningún momento un estado en el que revertir el código rompa la aplicación. Es un ejemplo perfecto de cómo las restricciones de operación se traducen en cómo se parten los commits.

GitOps es un modelo operativo con una premisa muy concreta:

El estado deseado del sistema está declarado en un repositorio Git. Un agente que corre dentro del sistema compara continuamente el estado real con el declarado y reconcilia las diferencias.

La diferencia con lo anterior es sutil pero importante: no es la tubería la que empuja los cambios al sistema, sino un agente dentro del sistema que tira de ellos.

La ventaja de seguridad es contundente y merece explicarse: en el modelo de empuje, tu sistema de CI necesita credenciales de escritura sobre producción. Eso convierte al CI en el objetivo más valioso de la organización. En GitOps, la tubería solo necesita permiso para escribir en un repositorio Git; el agente, que vive dentro del sistema, tira de los cambios. Nada externo tiene acceso a producción.

Desplegar es literalmente hacer un commit:

El agente detecta el commit en cuestión de segundos y reconcilia.

Y la promoción a producción es igual de simple:

Fíjate en la elegancia: la promoción entre entornos es copiar una línea de un fichero a otro. No se reconstruye nada, no se vuelve a etiquetar nada. Es la materialización literal de "construir una vez, desplegar muchas".

Si un commit en el repositorio de estado despliega en producción, entonces el control de acceso al repositorio ES el control de acceso a producción. Eso obliga a tomarse en serio lo que vimos en la lección 07-06:

Y una consecuencia organizativa: la separación entre "repositorio de aplicación" y "repositorio de estado" deja de ser una manía y se convierte en una decisión de seguridad. En el primero se desarrolla; en el segundo se despliega. Cada uno con sus permisos.

La propiedad más valiosa de GitOps es la detección de deriva. Si alguien cambia algo a mano en producción —para "arreglarlo rápido" a las tres de la mañana—, el agente detecta que el estado real no coincide con el declarado y lo revierte.

Es incómodo la primera vez que te pasa. Y es exactamente lo que debe ocurrir: obliga a que todo cambio pase por Git, que es lo que hace que el repositorio siga siendo la fuente de verdad. Sin esa reconciliación, "todo está en Git" es una afirmación que se degrada silenciosamente hasta ser falsa.

Retomamos la lección 08-05 con el matiz de la automatización.

Los secretos nunca van en Git. Ni cifrados con una contraseña débil, ni "solo este de pruebas", ni "es un repositorio privado".

La razón, que ya conoces bien: en Git, borrar no elimina. Un secreto confirmado está en el historial para siempre a menos que se reescriba y se coordine con todo el mundo, y aun así ya ha estado expuesto a todo el que clonara.

Ese bloque permissions: id-token: write merece explicación, porque es la práctica moderna: en lugar de guardar una credencial de larga vida en el sistema de CI, la tubería obtiene un token de corta duración demostrando su identidad. Si alguien roba ese token, caduca en minutos y solo sirve para ese repositorio y esa rama.

Hay un patrón aceptable, muy usado en GitOps, donde los secretos sí viven en el repositorio pero cifrados con una clave que no está allí:

El valor cifrado está en Git; la clave para descifrarlo vive en un servicio de gestión de claves al que solo el agente de despliegue tiene acceso. Ventajas: los secretos se versionan, se revisan y se auditan como todo lo demás. Requisito: que la clave nunca entre en el repositorio, y que rotarla sea un procedimiento probado.

Como en la lección 08-05, tres capas:

Más el hook de servidor (06-01) y el .gitignore (08-03). Y el procedimiento por si aun así ocurre, que empieza siempre por lo mismo: revocar el secreto primero, limpiar el historial después.

Aquí se cobra la inversión de la lección 08-01. Los Conventional Commits no eran solo una convención estética: son datos estructurados que una máquina puede leer.

Un feat y un fix sin cambios incompatibles: la siguiente versión es 1.4.0.

Ese git push origin "$VERSION" del final es lo que dispara la tubería de despliegue a producción del apartado 3. El circuito se cierra: de los mensajes de commit sale la versión, de la versión sale la etiqueta, y de la etiqueta sale el despliegue.

Es la mejor justificación posible para la disciplina del módulo 8. Un mensaje mal escrito ya no es solo feo: produce una versión incorrecta y un changelog que miente.

Algo falla. ¿Qué se hace?

Opción A: git revert y volver a desplegar.

Opción B: redesplegar el artefacto anterior.

La fila decisiva es la segunda: un git revert genera un commit que nunca ha estado en producción. Estás desplegando código nuevo para arreglar un incidente. Redesplegar el artefacto anterior es volver a un estado que sabes con certeza que funcionaba, porque estuvo funcionando hasta hace diez minutos.

Y la primera fila es la que decide en la práctica: durante un incidente, la diferencia entre segundos y minutos es la diferencia entre un susto y una postmortem.

Primero se restablece el servicio. Después se arregla el código. Son dos actividades distintas y mezclarlas alarga la incidencia.

Y el paso 3 no es opcional: si solo redespliegas la versión anterior, main sigue conteniendo el cambio malo, y el siguiente despliegue de cualquier persona lo volverá a llevar a producción. Hay que dejar main en un estado sano, ya sea con un revert o con una corrección.

Aún más simple, porque revertir el despliegue es revertir un commit del repositorio de estado:

Aquí sí es un git revert, pero fíjate en la diferencia: se revierte el commit de despliegue, no el commit de código. El resultado es que el fichero de estado vuelve a apuntar al artefacto anterior, que ya existe y ya funcionaba. Es la opción B expresada como un commit, con la trazabilidad de la opción A.

Un guion así, probado y con permisos claros, es la diferencia entre una reversión de treinta segundos y una de veinte minutos buscando en el historial de la terminal a las tres de la madrugada. Escríbelo y pruébalo un martes por la mañana, no durante un incidente.

• El fallo no es urgente: un error visual, algo que afecta a poca gente.
• El artefacto anterior no es desplegable: hubo una migración de datos irreversible entremedias.
• El cambio malo se detecta antes de llegar a producción, en preproducción.
• Se quiere que el historial refleje explícitamente que ese cambio se deshizo.

Recopilación final de prácticas, cada una con su motivo.

Si la tubería está definida en un fichero YAML versionado, sus cambios se revisan, se revierten y tienen historial. Si está configurada haciendo clic en una web, no hay historial, no hay revisión y nadie sabe quién cambió qué.

Es exactamente el mismo principio que rige todo el curso: identificar por contenido, no por nombre móvil. Una etiqueta se puede mover; un hash, no.

Ejecutar la tubería dos veces sobre el mismo commit debe producir el mismo resultado. Si la segunda ejecución falla porque "la etiqueta ya existe" o "el artefacto ya está publicado", la tubería no es idempotente y cualquier reintento se convierte en una intervención manual.

El mensaje debe decir qué ha pasado y qué hacer. Un error que solo dice exit 1 obliga a leer el guion.

Un despliegue anotado así se investiga en un minuto seis meses después.

Antes de tocar producción, verificar:

Si la CI ejecuta npm test y tú también, reproducir un fallo es trivial. Si la CI ejecuta doce pasos escritos en el YAML que no existen en ningún guion, no puedes reproducir nada. Extrae la lógica a guiones del repositorio y que la tubería solo los invoque.

La protección de main (07-06) es la última barrera. Con despliegue continuo, un push --force a main puede desplegar cualquier cosa. Prohibido, sin excepciones ni "cuentas de emergencia".

Error 1: reconstruir el artefacto en cada entorno. Lo que pruebas deja de ser lo que despliegas. Construir una vez, desplegar muchas; lo que cambia entre entornos es la configuración inyectada.

Error 2: usar latest como identificador. No identifica nada. El hash completo del commit como etiqueta canónica, y los nombres legibles como alias.

Error 3: git revert como primera reacción a un incidente. Despliega código nuevo sin probar para arreglar un problema urgente. Primero redesplegar lo anterior, después arreglar main.

Error 4: olvidar fetch-depth: 0 cuando la tubería usa git describe o compara ramas. Es el error de la lección 10-04: con un clon superficial no hay etiquetas ni base de fusión. Y en repositorios grandes, fetch-depth: 0 + filter: blob:none.

Error 5: secretos en el repositorio "porque es privado". Un repositorio privado tiene decenas de clones, réplicas, copias de seguridad y sistemas de CI con acceso. La regla no admite matices.

Error 6: etiquetas ligeras para producción. Sin autor, sin fecha, sin mensaje, sin firma. Y se pueden mover con git tag -f, cosa que un objeto de etiqueta anotada y firmada hace mucho más difícil de disimular.

Error 7: cambiar producción a mano. Crea deriva y el repositorio deja de ser la fuente de verdad. Si un cambio urgente es inevitable, el commit correspondiente se hace inmediatamente después, sin excepción.

Error 8: migraciones de base de datos no compatibles hacia atrás. Hacen imposible la reversión. Es la restricción operativa que más condiciona cómo se parten los commits.

Consejo 1: expón /version en la aplicación. Con el hash del commit. Responde a "¿qué hay realmente en producción?" sin acceso al sistema de despliegue.

Consejo 2: escribe el guion de reversión antes de necesitarlo. Y pruébalo. Un martes por la mañana.

Consejo 3: usa git describe --dirty para detectar construcciones no reproducibles. El sufijo -dirty significa que ese artefacto no se puede reconstruir desde el repositorio: rechazarlo.

Consejo 4: separa el repositorio de aplicación del de estado. Permisos distintos, historial de auditoría separado, y menos posibilidades de que un cambio de código toque producción por accidente.

Consejo 5: un panel que compare lo desplegado con main. git rev-list --count $DESPLEGADO..origin/main dice cuántos commits esperan. Es la métrica de "cuánto valor está parado".

Consejo 6: firma las etiquetas de producción. Así crear una versión requiere una clave privada, no solo permisos de escritura en el repositorio.

El equipo quiere:

• Cada integración en main despliega automáticamente a preproducción.
• Producción se despliega solo al crear una etiqueta anotada y firmada vX.Y.Z.
• El artefacto se construye una vez y se reutiliza.
• Debe ser posible revertir producción en menos de un minuto.

Escribe la tubería (o tuberías) en YAML, indicando qué comprobaciones de Git incluyes en cada punto y por qué. Explica el flujo completo de un cambio, desde la propuesta hasta producción.

Son las 03:12. Alerta: gestor-tareas devuelve error 500 en producción. Lo único que sabes es que el contenedor desplegado es:

Escribe la secuencia de comandos para:

1. Identificar qué versión y qué cambios contiene.
2. Determinar si el problema entró con el último despliegue.
3. Encontrar el commit sospechoso.
4. Revertir producción.
5. Dejar main en un estado sano.

Explica en qué orden lo harías y por qué.

Revisa esta tubería y señala todos los problemas, ordenados por gravedad, explicando qué puede fallar y cómo lo corregirías:

Solución 1

Tubería 1: integración (ya existe, de la lección 07-06). Pruebas y linter en cada propuesta, main protegida.

Tubería 2: construcción y despliegue a preproducción.

Comprobaciones incluidas y por qué:

Tubería 3: producción por etiqueta.

Tubería 4: reversión rápida (el requisito de "menos de un minuto").

Es rápida precisamente porque no construye nada: el artefacto ya existe desde el día en que ese commit entró en main.

Flujo completo de un cambio:

1. Ana crea GT-231-filtro-ocultas, trabaja, abre la propuesta.
2. CI ejecuta pruebas y linter (07-06). Bruno revisa y aprueba.
3. Se integra en main (rama protegida, squash).
4. La tubería 2 construye el artefacto :4f8a2e6... una vez y despliega a preproducción.
5. El equipo valida en preproducción.
6. Cuando toca publicar: ./herramientas/siguiente-version.sh calcula v1.4.0 desde los Conventional Commits, se genera el changelog y se crea git tag -a -s v1.4.0.
7. El push de la etiqueta dispara la tubería 3, que verifica y despliega el artefacto ya construido en el paso 4.
8. Si algo falla: tubería 4 con v1.3.0, en segundos. Después, git revert en main con calma.

Solución 2

El orden importa muchísimo, y es contraintuitivo: primero se restablece el servicio, después se investiga. Pero con una salvedad: los pasos 1 a 3 cuestan segundos y dan la información necesaria para revertir con criterio.

Si la etiqueta se creó a las 03:05 y la alerta saltó a las 03:12, el problema entró con este despliegue. Esa correlación es lo que justifica revertir en lugar de investigar.

Por qué aquí y no después: cada minuto de investigación es un minuto de servicio caído. El artefacto de v1.3.0 estuvo funcionando hasta hace veinte minutos: es la opción de riesgo cero.

Por qué NO hacer git revert ahora: generaría un commit nuevo, habría que construirlo (minutos), probarlo y desplegarlo, y ese artefacto nunca ha estado en producción. Es exactamente lo que no se quiere durante un incidente.

Con solo tres commits, bisect es exagerado; se usaría en un rango de cincuenta. Aquí, leer los tres diffs es más rápido.

Por qué el paso 9 es obligatorio: si solo se redesplegó v1.3.0, main sigue conteniendo el fallo. La próxima persona que publique una versión lo llevará otra vez a producción sin saberlo. La reversión del despliegue restablece el servicio; solo el paso 9 arregla el problema.

Solución 3

Ocho problemas, de más grave a menos.

1. CRÍTICO — Secreto en texto claro en el guion.

La contraseña de la base de datos de producción está en un fichero versionado, en el historial para siempre, visible para todo el que clone, y probablemente en los registros de cada ejecución de la tubería. Viola la lección 08-05 de la forma más directa posible.

Corrección: revocar la contraseña ahora mismo (antes que nada), guardarla en el gestor de secretos, inyectarla como variable de entorno del sistema de CI y, si el repositorio es público o ha sido clonado, limpiar el historial con git filter-repo (08-05).

2. CRÍTICO — Despliegue a producción sin ninguna barrera.

Cualquier integración en main va directa a producción, sin environment, sin aprobación, sin comprobaciones previas, sin preproducción. Un cambio de una línea mal revisado llega a los usuarios en dos minutos.

Corrección: separar en dos tuberías (integración a preproducción por rama; producción por etiqueta anotada y firmada), y declarar environment: produccion con revisores obligatorios.

3. GRAVE — latest como identificador.

No identifica nada. Imposible saber qué se está ejecutando, imposible revertir a una versión concreta, imposible reproducir un problema. Y una condición de carrera evidente: si dos integraciones ocurren seguidas, la segunda puede sobrescribir latest mientras la primera despliega.

Corrección: etiquetar con el hash completo del commit y usar los nombres legibles solo como alias.

4. GRAVE — Se reconstruye en cada despliegue y no hay separación construcción/despliegue.

No hay entorno de preproducción, así que lo que llega a producción no se ha probado nunca desplegado. Y como se construye aquí mismo, no hay forma de garantizar que el artefacto de producción sea el mismo que pasó las pruebas.

Corrección: construir una vez con el hash, desplegar ese mismo artefacto en preproducción y luego en producción.

5. GRAVE — La versión sale de un fichero VERSION y la etiqueta es ligera.

Tres problemas en tres líneas:

• Etiqueta ligera (git tag sin -a): sin autor, sin fecha, sin mensaje, sin firma.
• Falla si la versión no cambió: git tag sobre una etiqueta existente da error y rompe la tubería. No es idempotente.
• El fichero VERSION se actualiza a mano: alguien lo olvidará.

Corrección: calcular la versión desde los Conventional Commits (apartado 8) y crear etiqueta anotada y firmada:

6. MEDIO — actions/checkout@main.

Referencia a una rama móvil: lo que la tubería ejecuta puede cambiar sin que nadie lo decida. Es un riesgo de cadena de suministro y de reproducibilidad.

Corrección: fijar por hash. Y añadir fetch-depth: 0 si se van a usar etiquetas o comparaciones.

7. MEDIO — Sin comprobaciones ni verificación posterior.

No comprueba nada antes de tocar producción, y no verifica nada después. La notificación dice "Desplegado" pase lo que pase, porque el curl se ejecuta igual: no hay if: success(), ni se comprueba que el servicio responda.

Corrección: comprobaciones previas (commit en main, copia limpia, artefacto existente) y una comprobación de vida contra /version que confirme el hash desplegado.

8. MENOR — ssh con docker compose como mecanismo de despliegue.

Sin control de versiones del estado, sin reversión, sin despliegue progresivo, sin registro. Si la conexión SSH se corta a mitad, el estado queda indeterminado.

Corrección: un guion de despliegue versionado en el repositorio (infra/desplegar.sh) que sea idempotente y registre lo que hace; y a medio plazo, valorar GitOps (apartado 6), que además elimina la necesidad de que la tubería tenga credenciales de producción.

Resumen de la corrección: esta tubería hace todo en un solo trabajo sin barreras, con un secreto en claro y sin identificación reproducible del artefacto. La reescritura correcta es la del ejercicio 1: separar construcción de despliegue, identificar por hash, exigir etiqueta anotada y firmada para producción, inyectar secretos desde el gestor, y añadir verificación antes y después.

Git deja de ser una herramienta de desarrolladores y pasa a ser la pieza central de la operación.

• El repositorio se convierte en la fuente única de verdad: no solo código, también infraestructura, configuración por entorno, migraciones y la definición de las propias tuberías. La regla: si algo puede romper producción, debe estar en Git; y si está en Git, no debe cambiarse fuera de Git. Con una excepción absoluta: los secretos.
• Integración, entrega y despliegue continuos se distinguen por dónde está el botón humano: la integración garantiza que lo que entra funciona, la entrega que lo que está en main puede desplegarse, y el despliegue que está desplegado. Quitar el botón es una decisión de confianza que exige pruebas fiables, reversión en minutos y cambios pequeños.
• Un despliegue se dispara por rama (preproducción), por etiqueta anotada y firmada (producción, cerrando la 05-05) o por aprobación manual sobre un commit. Las verificaciones que importan son de Git puro: git cat-file -t para exigir etiqueta anotada, git tag --verify para la firma, y git merge-base --is-ancestor para exigir que esté en main.
• El artefacto se identifica por el hash completo del commit, y se construye una vez y se despliega muchas. Es la misma idea que sostiene todo Git: identificar por contenido, no por un nombre que se mueve. De ahí sale la trazabilidad completa —del contenedor al ticket en cinco comandos— y el git describe --dirty que detecta construcciones no reproducibles.
• La infraestructura como código da a los servidores todo lo que Git sabe hacer: historial, blame, revisión, revert. Y las migraciones de base de datos imponen la restricción que más condiciona los commits: deben ser compatibles hacia atrás durante al menos un despliegue, porque el código se revierte y los datos no.
• GitOps invierte el sentido: un agente dentro del sistema tira del estado declarado y reconcilia. Gana en seguridad (la tubería no tiene credenciales de producción), detecta y corrige la deriva, y convierte el historial de Git en el registro de auditoría. A cambio, el control de acceso al repositorio es el control de acceso a producción, y las ramas protegidas dejan de ser una recomendación.
• Los secretos se inyectan, nunca se versionan; y la práctica moderna sustituye las credenciales de larga vida por tokens de corta duración obtenidos por identidad federada.
• El versionado y el changelog automáticos cobran la inversión de la 08-01: los Conventional Commits son datos estructurados de los que salen la versión SemVer, el changelog y —vía etiqueta— el despliegue.
• Y la reversión en producción es casi siempre redesplegar el artefacto anterior, no git revert: el artefacto anterior estuvo funcionando hace diez minutos y está listo en segundos, mientras que un revert genera código nuevo sin probar que hay que construir y desplegar. Primero se restablece el servicio; después se deja main sano, que no es opcional.

La idea que atraviesa toda la lección:

En una organización con despliegue automatizado, git push deja de significar "he guardado mi trabajo" y pasa a significar "esto llegará a los usuarios". Todo el rigor del curso —commits atómicos, mensajes que explican el porqué, historial limpio, etiquetas anotadas, ramas protegidas— deja de ser una virtud profesional y se convierte en un requisito operativo.

Ya sabes usar Git en todos los contextos que existen hoy: solo, en equipo, en proyectos enormes y en producción automatizada. Queda una última pregunta, que es la más honesta que puede hacerse al final de un curso técnico: ¿cuánto de esto seguirá siendo cierto dentro de diez años?

Git no está quieto. Hay cosas que ya existen y puedes usar hoy aunque casi nadie las conozca: un formato de referencias nuevo que sustituye a refs/ y packed-refs, un git que puede funcionar con SHA-256 en lugar de SHA-1, los clones parciales y el índice disperso que acabamos de ver, y la consolidación de switch y restore frente al viejo checkout. Y hay cosas que son tendencia o especulación, que conviene distinguir con claridad de las anteriores.

También hay algo que casi con seguridad no va a cambiar, y es precisamente lo que aprendiste en el módulo 1: el modelo de datos direccionable por contenido, el grafo dirigido acíclico de commits y la naturaleza distribuida. Por eso lo que llevas aprendido no caduca.

La lección 10-06: El Futuro de Git cierra el curso: qué está maduro y qué es promesa, hacia dónde apuntan las herramientas, cómo seguir aprendiendo por tu cuenta, y una recapitulación completa del camino recorrido.