Las cinco lecciones anteriores eran laboratorios: cada paso estaba escrito, cada fichero estaba dado y cada fallo estaba previsto. Esta no. Esta es el encargo. Aquí tienes un contexto de empresa, unas restricciones, un presupuesto y una lista de requisitos con sus criterios de aceptación, y a partir de ahí decides tú: qué herramienta, qué estrategia de despliegue, qué pruebas escribir primero, qué escaneos ejecutar en cada PR y cuáles solo en main, dónde poner las puertas, qué dejar fuera y —lo más difícil— cómo justificar cada una de esas decisiones ante alguien que no estaba cuando las tomaste.

Puedes hacerlo sobre un proyecto tuyo (mejor, si tienes uno) o sobre Mini-Reservalia. Lo que no puedes es copiar el pipeline de la 07-05 tal cual: el contexto del encargo tiene restricciones que obligan a apartarse de él en al menos tres puntos, y encontrarlas forma parte del ejercicio.

1. El encargo
2. El contexto: Citas Norte, S.L.
3. Requisitos obligatorios y criterios de aceptación
4. Entregables
5. Rúbrica de autoevaluación
6. Plan de trabajo en cinco sesiones
7. Retos opcionales
8. Errores típicos del proyecto final
9. Errores Comunes y Consejos
10. Ejercicios
11. Conclusión y cierre del curso en la práctica

Te incorporas como responsable de entrega a una empresa pequeña que tiene un producto en producción y ningún pipeline. Despliegan a mano, los viernes no despliegan, y la última vez que algo salió mal tardaron dos horas en volver atrás porque nadie recordaba qué versión estaba antes.

Tu encargo: llevar ese producto desde el estado actual hasta un pipeline completo de extremo a extremo, con puertas de calidad, artefacto inmutable, despliegue automatizado con rollback y métricas que demuestren que la situación ha mejorado.

La condición del encargo: todo lo que construyas tiene que poder ser verificado por un revisor externo que no ha hablado contigo, en menos de una hora, mirando solo el repositorio.

Esa última condición es la que convierte el ejercicio en algo parecido al trabajo real. Un pipeline que solo funciona cuando tú estás delante para explicarlo no es un entregable: es una dependencia.

Las restricciones son las que hacen que las decisiones tengan que justificarse. Si todo fuera posible, no habría nada que decidir.

La empresa. Citas Norte, S.L. vende un software de reservas para pequeños negocios. Tiene:

Las restricciones, que son innegociables:

1. Presupuesto de herramientas: 0 €/mes. La empresa no aprueba gasto nuevo hasta el próximo ejercicio. Todo debe caber en planes gratuitos.
2. Nadie puede dedicarse a operar el pipeline. El equipo son tres personas y las tres están al 100 % en producto. Un Jenkins autoalojado está descartado por esto, no por lo técnico.
3. La ventana de mantenimiento actual es sagrada para el negocio: los sábados por la mañana, entre las 9:00 y las 13:00, se concentra el 40 % de las reservas del fin de semana. Una caída ahí cuesta clientes.
4. Hay datos personales (nombre, teléfono y email de los clientes finales de los 180 negocios). Cualquier filtración es un incidente reportable.
5. La tech lead se va de vacaciones tres semanas dentro de dos meses. Durante ese tiempo, las otras dos personas tienen que poder desplegar y revertir sin ella.
6. El equipo desconfía de la automatización. El backend, en concreto, ha dicho literalmente: "cada minuto que le dediquemos a esto es un minuto que no dedicamos a lo que nos pagan". Tu propuesta tiene que rendir pronto y tienes que poder demostrarlo con números.

Tres consecuencias de leer bien las restricciones (compruébalas contra tus decisiones cuando termines):

• La restricción 2 y la 6 juntas descartan cualquier solución que requiera mantenimiento continuo. Menos piezas y más estándar gana a más potente.
• La restricción 5 significa que el rollback tiene que ser ejecutable por alguien que no lo escribió, con un botón y sin recordar comandos. Documentar no es opcional aquí: es un requisito funcional.
• La restricción 3 no significa "ventanas de despliegue". Significa que el tiempo de restauración importa más que la frecuencia. Si puedes revertir en 3 minutos, el sábado deja de dar miedo; si tardas 2 horas, ninguna ventana te salva.

La línea base que tienes que medir antes de tocar nada (es el requisito más incumplido de todo el proyecto):

Cada requisito lleva su criterio verificable. La fórmula "un revisor externo debe poder comprobar que…" es deliberada: si no se puede comprobar mirando el repositorio y sus ejecuciones, no cuenta.

Total: 29 requisitos. No se espera que todos queden impecables; se espera que todos estén considerados y que las ausencias sean decisiones documentadas, no olvidos.

Público (o privado con acceso al revisor), con historial real: ramas, PR, checks, runs con éxito y runs con fallo. Un repositorio con un solo commit gigante no demuestra un pipeline; demuestra un fichero.

Estructura sugerida:

Este es el entregable que más se nota y el que peor se hace. No es documentación de qué hace el pipeline —eso se lee en el YAML—: es el registro de por qué es así y qué se sacrificó.

Plantilla mínima:

La sección "Qué NO hemos hecho y por qué" es la que distingue un trabajo profesional de un ejercicio. Un pipeline sin límites explícitos es un pipeline que crecerá sin control hasta que alguien lo abandone.

Provoca un fallo real, déjalo llegar hasta donde tu pipeline lo detenga, y escribe el post-mortem. Sugerencias de fallo, en orden de dificultad:

Estructura del post-mortem, sin culpables:

Un panel de Grafana versionado, o —si no montas Prometheus— un $GITHUB_STEP_SUMMARY de un job programado con las cuatro DORA, el estado del SLO y el consumo del presupuesto de error. Lo que se evalúa es que exista una superficie donde alguien que no eres tú pueda ver cómo va la cosa sin pedirte nada.

Aplícatela con honestidad. La columna "Insuficiente" describe lo que la mayoría entrega en el primer intento.

Cómo puntuarte: cuenta cuántas filas caen en cada columna.

• Mayoría en Insuficiente: tienes un pipeline que funciona pero no es defendible. Prioriza el grupo A y el B4/B6.
• Mayoría en Correcto: es un pipeline profesional, entregable. Es el objetivo realista del curso.
• Varias en Excelente: estás por encima de lo que tienen muchos equipos en producción. Elige dos o tres para llevar a excelente en vez de subir todas a la vez.

Cinco sesiones de 2-4 horas. El orden no es arbitrario: cada sesión deja algo funcionando y medible, y ninguna depende de terminar la siguiente para aportar valor. Es el mismo principio de los siete incrementos de la 05-04.

1. Mide la línea base. Las cuatro DORA con los datos que tengas, aunque sean aproximados. Anótalas en PIPELINE.md hoy, porque dentro de tres semanas no podrás reconstruirlas.
2. Consigue que el proyecto se verifique con un solo comando: npm ci && npm run lint && npm test && npm run build. Si eso no funciona en una máquina limpia, arréglalo antes de escribir una línea de YAML.
3. Escribe la prueba que falta para el bug más reciente que hayáis tenido.
4. Commitea el lockfile si no está.

Entregable de la sesión: un comando que verifica el proyecto y la línea base escrita.

1. ci.yml incremental, como en la 07-01: primero que se ejecute, luego que instale y pruebe, luego jobs en paralelo, luego caché. Mide los tiempos en cada paso y anótalos.
2. Las tres capas de pruebas (07-02). Empieza por la que más miedo te da romper.
3. Cobertura con umbral 2-3 puntos por debajo del valor actual.
4. Protección de main con un job agregador como único check requerido.
5. Rompe algo a propósito y comprueba que bloquea.

Entregable: A1-A6 cumplidos, con los tiempos antes/después de la caché.

1. Dockerfile multi-etapa, no-root, HEALTHCHECK (07-03).
2. Publicación en el registro por digest, con el digest visible en el resumen.
3. scripts/desplegar.sh idempotente y ejecutable en local. Escríbelo antes que el YAML: si empiezas por el YAML, acabarás con lógica dentro del YAML.
4. scripts/smoke.sh que verifique salud, funcionalidad y versión.
5. cd.yml con dos entornos y aprobación en el segundo.
6. rollback.yml cronometrado. Ejecútalo y anota el tiempo.
7. Provoca un despliegue malo y comprueba que el smoke test lo detiene.

Entregable: B1-B7 cumplidos, con el run del rollback cronometrado y el run del despliegue bloqueado.

1. Auditoría de lo que llevas construido, con la lista de la 07-05.
2. permissions de mínimo privilegio, provocando un fallo para entenderlo.
3. Acciones por SHA + Dependabot.
4. Los cinco escaneos, uno cada vez, comprobando que cada uno detecta algo real antes de pasar al siguiente.
5. Política de severidades escrita y el job de caducidad de excepciones.
6. SBOM, firma y verificación antes de desplegar.

Entregable: D1-D6, con evidencia de que cada escaneo ha detectado algo.

1. /metricas con las señales de oro (07-04).
2. SLO con la aritmética del presupuesto escrita.
3. Una alerta por síntoma, disparada a propósito y con captura.
4. Job programado de DORA. Ejecútalo dos veces con días de diferencia para tener tendencia.
5. Provoca el fallo del post-mortem y escríbelo.
6. PIPELINE.md completo, incluida la sección de qué no has hecho.
7. Pásate la rúbrica.

Entregable: E1-E5, PIPELINE.md, POSTMORTEM.md y la autoevaluación.

Consejo sobre el ritmo. Si vas corto de tiempo, sacrifica el grupo E antes que el B. Un pipeline que despliega y revierte pero no se mide es incompleto; uno que se mide pero no puede revertir es peligroso. Y si tienes que elegir un solo requisito de los 29, que sea B6: rollback cronometrado. Es el que convierte el miedo en un número.

Para cuando lo básico esté cerrado. Cada uno vale por sí solo.

El más instructivo de todos, si quieres cerrar el curso con algo que te cambie la perspectiva, es la matriz de dos herramientas: reimplementar el pipeline en GitLab CI te obliga a separar lo que es tu proceso de lo que es sintaxis de GitHub, y esa separación es exactamente la que la 06-07 defendía. Se tarda menos de lo que parece —el trabajo real ya está en los scripts— y el resultado es una tabla de equivalencias que has escrito tú.

Estos tres son, con diferencia, los que más se repiten. Los tres tienen la misma forma: hacer la parte visible antes que la parte que la sostiene.

Cómo se manifiesta. Se abre ci.yml y se empieza a escribir. A los tres días hay 200 líneas de YAML con run: | de veinte líneas cada uno, y la única forma de probar un cambio es hacer push y esperar cuatro minutos.

Por qué es grave. El ciclo de depuración pasa de segundos a minutos, y multiplicado por cada intento. Un problema que en local se resuelve en cinco iteraciones de diez segundos se convierte en cinco iteraciones de cuatro minutos, con commits de "arreglar CI", "arreglar CI 2", "ahora sí". Además, esa lógica no es testeable, no es revisable y no se puede ejecutar en una emergencia si el CI está caído.

El orden correcto:

Prueba de fuego: ¿puedes desplegar sin GitHub Actions? Si la respuesta es no, la lógica está en el sitio equivocado.

Cómo se manifiesta. Un pipeline precioso que despliega en noventa segundos... el código roto. Las pruebas existen, pasan siempre, y no cubren nada de lo que se rompe de verdad.

Por qué es grave. Automatizar el despliegue multiplica la velocidad a la que llegan los cambios a producción. Si la verificación es débil, lo que has multiplicado es la velocidad a la que llegan los bugs. Un pipeline rápido sobre pruebas malas es objetivamente peor que el despliegue manual del principio, porque el manual al menos incluía a una persona mirando.

El orden correcto: una prueba que detecte el último bug real que tuvisteis, antes de automatizar el despliegue. Si no puedes escribirla, no automatices todavía: automatiza solo hasta staging y deja producción manual hasta que la red de seguridad exista.

La señal de alarma: si tu suite nunca ha estado en rojo por un bug real —solo por errores de sintaxis—, no está probando nada.

Cómo se manifiesta. Tres semanas de trabajo, un pipeline excelente, y en la reunión con la dirección: "¿y esto qué ha mejorado?" — "Pues... va todo mucho mejor".

Por qué es grave. Es el error que hace que la siguiente inversión no se apruebe. Recuerda la restricción 6 del contexto: el backend ya piensa que esto es tiempo robado al producto. Sin números, tiene razón él, porque su escepticismo sí está basado en algo concreto (las horas invertidas) y tu defensa no.

Y hay un agravante técnico: la línea base no se puede reconstruir a posteriori. Una vez que el pipeline está montado, el "antes" ya no existe. Es información que se destruye al hacer el trabajo.

El orden correcto: medir en la sesión 1, antes de tocar nada, aunque sea con estimaciones toscas. Cuatro números y la fecha. Diez minutos de trabajo que valen por las tres semanas siguientes.

Cómo se presenta después:

Esa última fila es la que cierra la discusión, y por eso conviene tenerla: traduce el trabajo a horas de personas, que es la unidad en la que piensa quien aprueba presupuestos. Es exactamente el argumento del TCO de la 06-07, aplicado a tu propio proyecto.

Síntoma: el proyecto se atasca en la sesión 3 y no llega a producción. Causa: intentar montar el entorno de destino "de verdad" (un VPS, Kubernetes, AWS) antes de tener el pipeline. Arreglo: usa un destino simulado como el de la 07-03 y termina el circuito completo. Un pipeline que despliega a un contenedor local pero cubre las siete piezas de B1-B7 vale infinitamente más que medio pipeline apuntando a infraestructura real. Cambia el destino al final; es la parte más fácil de cambiar.

Síntoma: 29 requisitos parecen inabordables y no se empieza. Causa: intentar hacerlos en paralelo. Arreglo: el plan de cinco sesiones está ordenado por dependencia. Haz A completo antes de tocar B. Un grupo terminado vale más que cinco a medias, porque los grupos incompletos no se pueden verificar.

Síntoma: el PIPELINE.md acaba siendo una descripción del YAML. Causa: documentar mientras se escribe el código, cuando aún no hay perspectiva. Arreglo: escribe cada decisión en el momento en que descartas una alternativa, con una línea: "descartado X porque Y". Al final, esas líneas son el documento. Si nunca descartaste nada, no tomaste decisiones: copiaste.

Síntoma: la rúbrica sale mayoritariamente en "Correcto" y no sabes qué mejorar. Consejo: no subas todo a "Excelente". Elige dos o tres con criterio: las que más reduzcan el riesgo en tu contexto concreto. Con las restricciones de Citas Norte, las tres candidatas obvias son el rollback (restricción 5), la verificación de firma (restricción 4, datos personales) y las DORA con tendencia (restricción 6, hay que convencer a alguien).

Consejo — no lo hagas todo tú. Si tienes con quién, pide a alguien que verifique tu repositorio siguiendo los criterios de aceptación, sin que le expliques nada. Los puntos donde tenga que preguntarte algo son exactamente los que te faltan por documentar. Es la prueba más barata y la más reveladora del proyecto.

Consejo — el pipeline nunca está terminado. Cuando cierres los 29 requisitos, el pipeline será bueno para el contexto de hoy. Con el doble de equipo y diez veces el tráfico, tres de tus decisiones serán incorrectas. Por eso cada decisión del PIPELINE.md lleva "cuándo revisar esta decisión": no es burocracia, es reconocer que un pipeline es un organismo vivo y que la alternativa a revisarlo es reescribirlo entero dentro de dos años.

Estos tres no son variaciones del laboratorio: son extensiones del propio proyecto final, pensadas para hacerlas después de entregarlo.

Intercambia repositorios con otra persona que haya hecho el proyecto (o audita un repositorio público real que use GitHub Actions). Aplica los 29 criterios de aceptación sin hablar con nadie y escribe un informe de auditoría con los hallazgos priorizados.

La restricción 5 del contexto: la tech lead se va tres semanas. Demuestra que el sistema sobrevive.

Reduce a la mitad el tiempo de tu pipeline sin quitar ninguna verificación. Documenta cada cambio con su medición.

Solución 1. Plantilla de informe de auditoría:

Lo que enseña este ejercicio: auditar el trabajo de otro es la forma más rápida de ver los agujeros del tuyo. Casi todo el mundo encuentra en el repositorio ajeno dos o tres cosas que también le faltan al propio y que no había visto en semanas.

Solución 2. El protocolo de la prueba:

Los tres fallos que aparecen casi siempre en este ejercicio, por si quieres adelantarte:

1. Encontrar el digest anterior. Nadie sabe dónde mirar. Arreglo: imprimirlo en el resumen de cada despliegue y aceptar el input vacío en el rollback (07-03 ejercicio 1).
2. La alerta no llegó a nadie. Estaba configurada en Prometheus pero sin destinatario. Arreglo: Alertmanager con un canal real, y una prueba de que llega.
3. El camino manual no existe. Todo el conocimiento está dentro del YAML. Arreglo: scripts/desplegar.sh ejecutable en local (requisito C2), documentado en el runbook con el comando literal.

Si tu proyecto pasa el escenario 3, has cumplido el criterio más exigente de todo el curso: el pipeline es una comodidad, no una dependencia.

Solución 3. La estrategia, en orden de rentabilidad:

La lección de este ejercicio es C3: la caché de Docker no funciona si el Dockerfile está mal ordenado, y mucha gente añade C2, no ve mejora y concluye que "la caché no sirve". El orden de las capas es el 80 % del resultado, y es gratis.

Si has llegado hasta aquí con el proyecto entregado, tienes en tu repositorio algo que muchos equipos en producción no tienen: un pipeline que integra, verifica en tres capas, construye un artefacto inmutable identificado por su contenido, lo escanea de cinco formas distintas, lo firma, lo despliega tras una puerta explícita, comprueba que el despliegue funcionó, promociona el mismo artefacto sin reconstruirlo, revierte en minutos —solo, si las métricas empeoran—, y se mide a sí mismo para poder demostrar que todo eso sirve de algo.

Pero el entregable que más va a durar no es el YAML. Son los dos documentos.

El PIPELINE.md, porque contiene lo único que no se puede deducir leyendo el código: por qué es así y qué se sacrificó a cambio. Dentro de un año, cuando alguien —quizá tú— se pregunte por qué no hay canary o por qué las acciones están fijadas por esos SHA raros, la respuesta estará escrita, con su fecha y con la condición que obligaría a revisarla. Un pipeline sin ese documento se reescribe entero cada dos años porque nadie se atreve a tocar lo que no entiende.

Y el POSTMORTEM.md, porque documenta la única prueba que de verdad importa: que el sistema falló y lo aguantó. Cualquiera puede enseñar un pipeline en verde. Enseñar uno que se puso en rojo por el motivo correcto, en el sitio correcto, y que se recuperó en tres minutos, es enseñar que funciona.

Hay una última cosa que este módulo te ha hecho hacer sin decírtelo explícitamente, y conviene nombrarla ahora. En cada laboratorio has roto algo a propósito: un test, un despliegue, un secreto, una consulta SQL, un endpoint lento. Eso no era decoración pedagógica. Es la práctica profesional que separa a quien tiene un pipeline de quien confía en su pipeline: verificar por el lado negativo. Cualquiera puede comprobar que un control deja pasar lo bueno; comprobar que detiene lo malo requiere fabricar lo malo, y casi nadie lo hace. Si te llevas una sola costumbre del curso, que sea esta: cada vez que añadas una puerta, provoca el fallo que debería detener, y no des la puerta por buena hasta haberlo visto.

Con esto se cierra la parte práctica y, con ella, la materia del curso. Has recorrido los principios (módulos 1 a 4), cuatro contextos reales (módulo 5), la maquinaria (módulo 6) y la construcción de extremo a extremo con tus manos (módulo 7). Lo que queda ya no es materia: es a dónde ir después.

El módulo 8 es el mapa de esa continuación. Las lecturas recomendadas —Continuous Delivery, Accelerate, The DevOps Handbook, el SRE Workbook— que dan el fundamento y los datos detrás de casi todo lo que has aplicado aquí. Las comunidades y foros donde se discuten estos problemas cuando se salen de lo que cabe en un curso. Las herramientas y plugins adicionales que quedaron fuera por espacio y que resuelven problemas concretos que ya sabrás reconocer: gestión de secretos con Vault, entrega progresiva con Flagger o Argo Rollouts, plataformas internas de desarrollo, políticas como código. Y la ruta de aprendizaje y certificaciones, con el orden razonable para profundizar según hacia dónde quieras moverte —plataforma, SRE, seguridad de la cadena de suministro— y qué certificaciones valen realmente la pena en cada caso.

Empieza por 08-01: Lecturas Recomendadas. Y, cuando lo hagas, léelo con el pipeline delante: ahora tienes un sistema real sobre el que probar cada idea, que es exactamente lo que faltaba la primera vez que abriste este curso.