Durante siete módulos el curso ha ido dejando puertas entornadas. En la 03-04 configuraste un canary moviendo pesos del ALB a mano y se dijo que existían herramientas que hacen eso solas analizando métricas. En la 04-03 guardaste los secretos en el almacén del repositorio y se dijo que llega un punto en que eso deja de bastar. En la 02-04 mediste cobertura y se admitió que la cobertura miente. En la 07-05 firmaste imágenes con Cosign y se mencionó un marco llamado SLSA sin desarrollarlo.

Esta lección abre esas puertas. Pero con una disciplina estricta, que es la misma que la 08-02 te enseñó a aplicar a los consejos ajenos: cada herramienta se presenta por el problema que resuelve, no por lo que es. Para cada una encontrarás el momento del curso donde el problema apareció, cómo encaja en el pipeline que ya tienes, un ejemplo breve de configuración y —la parte que casi nunca se escribe— cuándo NO la necesitas.

No es un tutorial de nada. Es un catálogo de reconocimiento: para que cuando un problema aparezca, sepas que existe algo que lo resuelve y qué te va a costar.

1. Gestión de secretos más allá del CI
2. Entrega progresiva automatizada
3. GitOps
4. Políticas como código
5. Calidad y análisis
6. Cadena de suministro
7. Pruebas
8. Desarrollo local y reproducibilidad
9. Plataforma interna
10. Observabilidad
11. Tabla de adopción por tamaño de equipo
12. El criterio para dejar entrar una herramienta
13. Errores Comunes y Consejos
14. Ejercicios
15. Conclusión

El problema, y dónde apareció. En la 04-03 y la 07-05 guardaste los secretos en el almacén de secretos del repositorio o de la organización. Funciona bien y es lo correcto para empezar. Deja de bastar cuando aparece alguna de estas cuatro condiciones:

1. El secreto lo necesita también la aplicación en ejecución, no solo el pipeline. El almacén del CI inyecta variables durante el workflow; no le sirve de nada al contenedor que lleva tres semanas corriendo en ECS.
2. Hay que rotar y no se puede. Rotar la contraseña de la base de datos implica cambiarla en el almacén del CI, en la definición de tarea y en la propia base de datos, coordinadamente y a mano.
3. Hace falta auditoría. "¿Quién leyó este secreto y cuándo?" El almacén del CI te dice quién lo editó, no quién lo usó.
4. Los secretos se multiplican por entornos y equipos y ya no caben en una lista plana.

Es la opción de menor fricción si ya estás en AWS, como Reservalia. El secreto se guarda en el servicio, la tarea de ECS lo recibe por referencia y nunca pasa por el pipeline: el workflow ya no ve la contraseña de la base de datos en ningún momento, lo que reduce la superficie de exposición de golpe.

El agente de ECS resuelve el ARN al arrancar la tarea usando el rol de ejecución. La rotación automática se configura en el propio servicio con una función Lambda.

Contrapartidas. Cuesta dinero por secreto y por llamada a la API —poco, pero Diego lo va a preguntar; Parameter Store con parámetros SecureString es la alternativa más barata y menos capaz—. Y te ata al proveedor: los ARN no se migran.

Cuándo NO lo necesitas. Si todos tus secretos son de pipeline (tokens de registro, credenciales de despliegue) y tu aplicación no consume ninguno en ejecución, el almacén del CI más OIDC es suficiente y más simple.

El gestor de secretos de propósito general y agnóstico de proveedor. Aporta dos cosas que un servicio de nube básico no da:

• Secretos dinámicos. En lugar de guardar una credencial de base de datos, Vault la genera bajo demanda con caducidad. La aplicación pide credenciales, recibe un usuario y contraseña válidos una hora, y Vault los revoca solos. Un secreto que caduca en una hora es un secreto que casi no se puede filtrar.
• Políticas y auditoría finas, con motor de identidad propio y registro de cada lectura.

Igual que con AWS en la 03-02, aquí no hay credencial de larga duración: el runner presenta su token OIDC y Vault decide si ese repositorio y esa rama pueden leer esa ruta.

Contrapartidas, y son grandes. Vault autoalojado es un sistema crítico más que operar: alta disponibilidad, sellado y desellado, copias de seguridad, actualizaciones. Si Vault cae, no despliega nadie y posiblemente no arranca nada. Es una pieza de infraestructura seria, y su versión gestionada cuesta dinero. La 06-01 decía de Jenkins que el coste real no es la licencia sino quién lo mantiene; con Vault pasa exactamente igual.

Cuándo NO lo necesitas. Casi siempre, con menos de 20 personas y una sola nube. La respuesta correcta para Reservalia es Secrets Manager, no Vault. Vault empieza a compensar con varias nubes, requisitos de auditoría estrictos o cuando los secretos dinámicos resuelven un problema de cumplimiento concreto.

Un enfoque distinto y muy infravalorado: cifrar los secretos y commitearlos. SOPS cifra solo los valores de un YAML o JSON, dejando las claves legibles, de modo que el git diff sigue siendo útil.

age es la herramienta de cifrado moderna que sustituye a GPG para este uso: claves cortas, sin anillo de claves, sin la complejidad histórica de GPG. En el pipeline, la clave de descifrado es el único secreto que vive en el almacén del CI — has reducido N secretos a uno.

Ventajas reales: los secretos se versionan, se revisan en PR, siguen la misma promoción que el código, y el historial dice quién cambió qué y cuándo. Contrapartidas: rotar un destinatario exige recifrar todos los ficheros; y aunque esté cifrado, el material está en el repositorio para siempre, así que un algoritmo roto o una clave filtrada dentro de cinco años compromete todo el histórico.

Cuándo sí es la elección correcta: equipos pequeños con muchos ficheros de configuración por entorno, sobre todo con Kubernetes, donde encaja de forma natural.

Específico de Kubernetes. Sincroniza secretos desde un gestor externo (Secrets Manager, Vault, etc.) hacia Secret nativos del clúster, para que las aplicaciones los consuman de la forma estándar sin saber de dónde vienen.

Cuándo NO lo necesitas. Si no usas Kubernetes, es irrelevante. Reservalia, en ECS, no lo necesita.

Y una regla que vale más que el diagrama: la mejor gestión de secretos es no tener el secreto. OIDC eliminó las claves de AWS del pipeline en la 03-02; los roles de IAM eliminan credenciales entre servicios de la nube. Cada secreto que consigues eliminar es uno que no hay que gestionar, rotar ni auditar.

El problema, y dónde apareció. En la 03-04 montaste un canary desviando un 10 % del tráfico con pesos de ALB, y luego alguien —tú— miraba Grafana y decidía si promocionar o revertir. Eso tiene tres defectos: depende de que haya un humano mirando, el criterio es subjetivo, y en la práctica se acaba promocionando por impaciencia.

La entrega progresiva automatizada convierte ese juicio en una especificación declarativa: qué métricas, qué umbrales, cada cuánto, y qué hacer si fallan.

Sustituye el Deployment de Kubernetes por un recurso Rollout que sabe hacer canary y blue-green con análisis automático.

Si la consulta supera el umbral una vez, el rollout revierte solo, sin que nadie mire nada. Es exactamente el rollback automático por métricas de la 03-05, pero declarado en el recurso en vez de escrito en un script del workflow.

Resuelve lo mismo con otra filosofía: en lugar de sustituir el Deployment, lo envuelve. Se declara un recurso Canary que referencia el Deployment existente, y Flagger orquesta el despliegue progresivo manipulando la malla de servicio o el ingress.

Fíjate en el webhook de tipo pre-rollout: es el smoke test de la 03-02, ejecutado contra la versión canary antes de enviarle tráfico real.

Diferencia práctica entre ambos. Argo Rollouts da control explícito paso a paso y encaja bien con Argo CD; Flagger es más automático y menos intrusivo con los manifiestos existentes. Ambos requieren métricas fiables y un control de tráfico capaz (malla de servicio, ingress compatible o proveedor de tráfico soportado).

Cuándo NO los necesitas —y es importante—. Los dos son exclusivos de Kubernetes. Reservalia está en ECS: no aplican. Y hay una condición previa más dura que la plataforma: necesitas métricas de calidad y volumen de tráfico suficiente. Un canary al 10 % en un servicio con 5 peticiones por minuto no genera señal estadística: 30 peticiones en cinco minutos no distinguen una tasa de error del 1 % de una del 4 %. En ese régimen, el análisis automático es teatro y un rolling con health checks más un rollback rápido es honestamente mejor.

La condición de entrada: tráfico suficiente para que una degradación del 1 % sea detectable en la ventana de análisis, métricas ya instrumentadas y en las que confías (03-06 hecha de verdad), y despliegues lo bastante frecuentes como para que automatizar el juicio compense configurarlo.

El problema, y dónde apareció. En la 03-02 tu cd.yml hace push: el pipeline tiene credenciales sobre producción y ejecuta el despliegue. Eso implica que el CI es una pieza con permisos muy altos, y que el estado real del entorno puede divergir del código sin que nadie se entere. Alguien toca algo a mano en la consola, y el repositorio deja de describir la realidad. La 03-03 lo llamó drift.

GitOps invierte la dirección: un agente dentro del clúster observa un repositorio y aplica lo que ahí esté. El pipeline ya no despliega: solo escribe en el repositorio de despliegues.

El patrón del repositorio de despliegues. Se separa el código de la aplicación de los manifiestos de despliegue. El CI, al publicar la imagen, hace commit del nuevo digest en el repositorio de despliegues; el agente lo detecta y reconcilia. El historial de git es el historial de despliegues, y revertir es un git revert.

selfHeal: true es el drift detection en su forma más contundente: si alguien edita algo a mano, se deshace solo en la siguiente reconciliación.

Argo CD frente a Flux. Argo CD tiene interfaz web y es más accesible para equipos que empiezan; Flux es más ligero, más orientado a CLI y a componerse con otras piezas. Ambos son proyectos graduados de la CNCF —con lo que eso significa según la 08-02— y la elección entre ellos rara vez es el factor decisivo.

Contrapartidas. Otra pieza que operar; dos repositorios y por tanto dos historiales que hay que saber correlacionar cuando algo falla; y una depuración menos directa ("¿por qué no ha sincronizado?" es una pregunta nueva). Además, no todo encaja: las migraciones de base de datos de la 04-06 no son declarativas y siguen necesitando su propio mecanismo.

Cuándo NO lo necesitas. Sin Kubernetes, no aplica en su forma canónica. Y con un solo entorno y un equipo pequeño, el cd.yml de la 03-02 con OIDC hace el mismo trabajo con muchas menos piezas. GitOps compensa con varios clústeres, varios entornos, varios equipos y cuando el drift es un problema real y medido, no hipotético.

El problema, y dónde apareció. En la 04-03 y la 03-03 estableciste reglas: los contenedores no corren como root, los buckets no son públicos, las acciones se fijan por SHA. Esas reglas viven hoy en la revisión de código, es decir, en la atención de un humano cansado un viernes por la tarde. Las políticas como código las convierten en una verificación automática que falla el PR.

OPA es un motor genérico de políticas; Rego, su lenguaje; Conftest, la herramienta que lo aplica a ficheros de configuración en el pipeline.

Lo potente es que se evalúa el plan, no el estado aplicado: la política falla antes de tocar nada, en el PR, con un mensaje que dice qué recurso y por qué. Es la puerta de calidad de la 02-05 aplicada a la infraestructura.

Y funciona sobre cualquier estructura de datos, incluidos tus propios workflows:

Esto convierte en automática la regla de la 07-05 que hasta ahora dependía de que alguien se acordara en la revisión.

Alternativa específica de Kubernetes que se escribe en YAML en lugar de en Rego, lo que baja mucho la barrera de entrada. Actúa como admission controller: rechaza recursos que violen la política en el momento de aplicarlos al clúster.

Es la regla del artefacto inmutable de la 02-06, aplicada por el clúster y no por la buena voluntad de quien escribe el manifiesto.

Contrapartidas. Rego tiene una curva de aprendizaje real y poco transferible. Y hay un riesgo mayor: una política mal escrita bloquea a todo el mundo. Se despliegan siempre primero en modo aviso (Audit), se observa qué rompen durante unas semanas, y solo entonces se pasan a bloqueo.

Cuándo NO lo necesitas. Con tres personas que se revisan los PRs entre ellas, escribir Rego para reglas que se aplican dos veces al mes es sobrecoste. Compensa cuando la regla es importante, se repite mucho, y hay más gente de la que cabe en una conversación —tres o cuatro equipos en adelante—. Excepción: si tienes una sola regla crítica que no puede fallar nunca, un grep en un paso del workflow la aplica igual de bien y en dos minutos.

El problema, y dónde apareció. La 02-05 montó ESLint, Prettier, tsc y una puerta de calidad. Faltan dos capas: análisis semántico más profundo, y los linters de las propias herramientas del pipeline, que es el hueco que casi todo el mundo tiene abierto.

Esta es la sección de mejor relación coste/beneficio de toda la lección. Cinco herramientas, todas gratuitas, todas de una línea:

Por qué importa más de lo que parece. La 04-05 insistía en que el pipeline es código y debe tratarse como tal. Estos linters son las pruebas unitarias del pipeline: detectan en segundos errores que, sin ellos, se descubren tras un ciclo completo de commit, espera y fallo. actionlint en particular ahorra la mayoría de las iteraciones de prueba y error con YAML de Actions.

Cuándo NO los necesitas: nunca. Son la excepción de esta lección: gratis, instantáneos y sin contrapartida. Si te llevas una sola herramienta, que sea esta línea.

Ya apareció en la 02-05. Aporta análisis semántico, seguimiento de deuda técnica en el tiempo y —lo más útil— el concepto de código nuevo: la puerta de calidad se aplica solo a lo que cambia el PR, no a los 200.000 errores heredados. Es lo que permite aplicarlo a un legacy como el de la 05-04 sin bloquear a nadie.

Contrapartidas. SonarQube autoalojado es un servicio más que mantener, con su base de datos; SonarCloud es gratuito solo para proyectos públicos. Y genera mucho ruido inicial que hay que calibrar o el equipo aprende a ignorarlo.

Búsqueda de patrones con conciencia de sintaxis. Su valor es que puedes escribir tus propias reglas en minutos, con una sintaxis parecida al código que buscas:

Frente a CodeQL (04-03), Semgrep es más rápido y mucho más fácil de extender; CodeQL es más profundo en análisis de flujo de datos. No compiten tanto como parece: Semgrep para las reglas tuyas, CodeQL para las vulnerabilidades genéricas.

Cuándo NO lo necesitas. Si aún no tienes reglas propias que quieras imponer, ESLint con sus plugins de seguridad cubre buena parte en un proyecto TypeScript. Semgrep entra cuando dices "esto ya lo hemos comentado tres veces en revisiones".

La 04-03 y la 07-05 cubrieron lo esencial. Aquí está lo que faltaba y el marco que lo ordena.

SLSA (Supply-chain Levels for Software Artifacts, slsa.dev) define niveles progresivos de integridad de la cadena de construcción. La idea central: poder demostrar que el artefacto que despliegas viene del código que crees, construido por el proceso que crees.

Su utilidad práctica no es certificarse: es tener vocabulario para decir dónde estás y qué te falta. En una entrevista o ante un cliente que pregunta por la cadena de suministro, "cumplimos SLSA nivel 2 y esta es la atestación" vale mucho más que enumerar herramientas.

Ya usados en la 07-05. Lo que conviene entender: la firma sin claves (keyless). En lugar de gestionar una clave privada —el problema que arruina la mayoría de intentos de firma—, Cosign obtiene un certificado efímero ligado a la identidad OIDC del workflow y registra la firma en un log público de transparencia (Rekor).

El error frecuente es verificar solo que existe firma. Sin --certificate-identity-regexp, cualquiera puede firmar esa imagen y la verificación pasará. La firma responde "¿quién?", no "¿es buena?".

• Syft genera SBOM (CycloneDX o SPDX) a partir de una imagen o un directorio.
• Grype escanea vulnerabilidades sobre ese SBOM.
• Trivy hace ambas cosas y además escanea IaC, secretos y configuración de Kubernetes. Es lo que usaste en la 07-05 y sigue siendo la elección sensata por consolidación.

Lo nuevo es Dependency-Track: un servicio donde almacenas los SBOM de todos tus artefactos desplegados y que te avisa cuando aparece una vulnerabilidad nueva que afecta a algo que ya está en producción.

Por qué esto importa y es el hueco real que deja el curso. Tu escaneo de la 07-05 responde "¿esta imagen tiene vulnerabilidades conocidas hoy?". La pregunta que rompe empresas es la inversa: "acaba de publicarse una vulnerabilidad crítica en una librería, ¿en cuáles de mis 40 servicios en producción está?". Sin un inventario de SBOM, esa respuesta cuesta días de trabajo manual. Con él, es una consulta.

Cuándo NO lo necesitas. Con dos servicios, el inventario cabe en tu cabeza. A partir de diez o quince artefactos desplegados, deja de caber.

Alternativa a Dependabot (04-02) considerablemente más potente:

Tres cosas que Dependabot no hace igual de bien: agrupar actualizaciones en un solo PR (10 PRs semanales pasan a 1), automerge condicional cuando el CI pasa, y pinDigests que fija automáticamente las acciones por SHA y las mantiene al día — resolviendo la tensión de la 08-02 entre fijar y quedarse atrás. Además cubre más gestores y más ficheros (Dockerfile, Terraform, workflows).

Contrapartidas. Más configuración y una curva más pronunciada. Y el automerge exige confiar de verdad en tu suite de pruebas: si tu CI tiene "verde falso" (04-04), acabas de automatizar la introducción de fallos.

Cuándo NO lo necesitas. Dependabot está integrado y basta hasta que el ruido de PRs sea insoportable. La señal de migrar: cuando la gente empiece a cerrar los PRs de dependencias sin mirarlos.

El problema. En la 02-04 las pruebas de integración usaban una base de datos como servicio del workflow, o dobles. Lo primero es configuración duplicada entre local y CI; lo segundo miente sobre el comportamiento real de PostgreSQL.

Testcontainers levanta dependencias reales en contenedores desde el código de la prueba, con ciclo de vida gestionado:

Ese test verifica una restricción de PostgreSQL que ningún doble puede simular. Y funciona igual en tu portátil que en el runner, sin duplicar configuración: es la reproducibilidad de la 02-03 aplicada a las pruebas.

Contrapartidas. Más lento (arrancar contenedores cuesta segundos) y necesita Docker disponible en el runner. Se mitiga reutilizando contenedores entre suites.

El problema, de la 05-03. Con varios servicios, las pruebas E2E completas son lentas y frágiles, pero sin ellas nadie sabe si un cambio en la API rompe a un consumidor.

Pact invierte el planteamiento: el consumidor declara qué espera, se publica ese contrato, y el proveedor verifica en su propio pipeline que lo cumple. Sin levantar los dos servicios juntos.

El valor real no es técnico sino organizativo: el proveedor descubre que va a romper a alguien antes de desplegar, en su propio CI y sin coordinar con nadie.

Cuándo NO lo necesitas. Con un solo backend y un solo frontend en el mismo repositorio y desplegados juntos —Reservalia— el contrato lo garantizan los tipos compartidos de packages/compartido y unas pocas pruebas de integración. Pact entra cuando los servicios se despliegan por separado y los equipos son distintos. Antes de eso es ceremonia.

Pruebas de carga como código, ejecutables en el pipeline:

Lo importante son los thresholds: si no se cumplen, k6 sale con código distinto de cero y el job falla. Eso convierte el rendimiento en una puerta de calidad más, no en un informe que nadie lee.

Dónde ponerlo. No en cada PR: en la rama principal tras el despliegue a staging, o en una ejecución nocturna. Es la única forma realista de detectar una regresión de rendimiento antes de que la detecte un cliente — el problema que apareció en la 07-04 con el endpoint lento.

Cuándo NO lo necesitas. Si tu tráfico está lejos de cualquier límite y no hay quejas de latencia, es optimización prematura convertida en tiempo de CI.

El problema, y es la respuesta honesta a la 02-04. La cobertura mide qué líneas se ejecutan durante los tests, no qué comportamiento se verifica. Un test sin una sola aserción da cobertura del 100 %. Es la métrica más fácil de engañar de todo el pipeline, y todo el mundo lo sabe pero pocos hacen algo.

El mutation testing hace lo que ninguna otra técnica: introduce fallos deliberados en tu código (cambia un > por un >=, invierte una condición, borra una llamada) y comprueba si algún test falla. Si nadie se queja, ese test no estaba verificando nada.

Es, literalmente, verificar por el lado negativo —la costumbre que la 07-06 señaló como la más valiosa del curso— aplicada automáticamente a la suite entera. La primera ejecución sobre un proyecto con 85 % de cobertura y 45 % de mutantes muertos es una experiencia formativa que ningún argumento sustituye.

Contrapartidas, y son serias. Es lentísimo: cada mutante ejecuta la suite. Por eso mutate apunta solo al dominio, incremental está activado, y se ejecuta semanalmente o bajo demanda, nunca en cada PR.

Cuándo NO lo necesitas. Si tu suite es pequeña o tu cobertura es baja, arregla eso primero. El mutation testing es una herramienta de refinamiento, no de arranque. Y en código de fontanería (controladores, mapeos) da mutantes supervivientes irrelevantes que solo generan ruido.

El problema. "En mi máquina funciona", que la 02-03 atacó desde el lado del build, sigue vivo del lado del entorno de desarrollo. Y su primo: el ciclo de commit-esperar-fallar para depurar un workflow.

Ejecuta workflows de GitHub Actions localmente en Docker.

Convierte un ciclo de 6 minutos en uno de 40 segundos. Limitaciones importantes: no emula fielmente los entornos con revisores, workflow_run, la caché de Actions ni los permisos del token. Sirve para la lógica de los pasos, no para el comportamiento de la plataforma. Con eso claro, ahorra mucho tiempo.

Define el entorno de desarrollo como código, en el repositorio:

El valor medible: el tiempo de incorporación de alguien nuevo pasa de un día a media hora. Y elimina la clase entera de bugs "yo tengo Node 18".

asdf y mise fijan versiones de herramientas por proyecto con un fichero declarativo:

Barato, útil y con adopción inmediata. Nix ofrece reproducibilidad mucho más fuerte —hasta las dependencias del sistema— a cambio de una curva de aprendizaje notoria. Nix es de las pocas herramientas de esta lección de las que se puede decir con honestidad: extraordinaria si el equipo entero se compromete, contraproducente si solo la entiende una persona.

Ejecuta verificaciones antes del commit, con un marco multi-lenguaje que va más allá de Husky (02-05):

Una advertencia que la 02-05 ya daba: los hooks locales son una comodidad, nunca una garantía. Se saltan con --no-verify. Todo lo que importe debe verificarse también en el CI. Gitleaks en pre-commit está bien porque evita el bochorno; Gitleaks en el CI es lo que te protege.

Backstage (creado en Spotify, hoy en la CNCF) es un portal de desarrollo: catálogo de servicios con dueño, plantillas para crear servicios nuevos ya con pipeline, documentación técnica junto al código y una interfaz única sobre herramientas dispersas.

La idea que sí importa: los golden paths. Un camino recomendado, documentado y automatizado para hacer lo habitual. "Crear un servicio nuevo" pasa de dos días de copiar y pegar a diez minutos con pipeline, observabilidad y alertas ya configuradas. Y —esto es lo que lo hace estratégico— quien se sale del camino puede hacerlo, pero asume el mantenimiento.

La advertencia, y es la más importante de la lección. Backstage es un proyecto de desarrollo de software en sí mismo: hay que desplegarlo, mantenerlo, escribir plugins y actualizarlo. Una plataforma interna sin usuarios es un proyecto de vanidad, y hay muchísimos: portales preciosos que nadie abre porque el equipo tenía diez servicios y ya sabía dónde estaba todo.

Cuándo NO lo necesitas. Casi siempre. La señal legítima: varios equipos, decenas de servicios, y gente perdiendo tiempo real y medible en encontrar quién es el dueño de qué o en montar servicios nuevos. Si puedes nombrar de memoria todos tus servicios y sus dueños, no lo necesitas.

Y el orden correcto: primero el golden path, después el portal. Una plantilla de repositorio con el pipeline ya montado —lo que la 04-05 llamaba workflows reutilizables— da el 80 % del beneficio con el 5 % del coste.

OpenTelemetry es el estándar transversal: un conjunto de APIs, SDKs y un colector que instrumentan trazas, métricas y logs de forma independiente del backend. Su valor no es técnico sino estratégico: instrumentas una vez y cambias de proveedor sin tocar el código.

Con las auto-instrumentaciones se obtienen trazas de HTTP, PostgreSQL y las librerías comunes sin escribir instrumentación manual. Es la ampliación natural de la 03-06, donde las trazas quedaron como el pilar menos desarrollado.

El resto del ecosistema completa los pilares: Prometheus (métricas, ya usado en la 07-04), Grafana (visualización), Loki (logs con el mismo modelo de etiquetas que Prometheus, lo que permite saltar de un pico a sus logs), Tempo (trazas). Sentry cubre otra cosa distinta y complementaria: errores de aplicación con traza de pila, agrupación inteligente y contexto de la versión desplegada — responde "qué excepción y en qué línea", que ni las métricas ni los logs contestan bien.

Métricas DORA automatizadas. Existen herramientas específicas para calcularlas, pero la conclusión honesta —la misma de la 07-04— es que las cuatro métricas se calculan con consultas a la API de tu forja y de tu sistema de incidentes, y que hacerlo tú te obliga a definir con precisión qué cuentas como despliegue y como fallo. Esa definición es la mitad del valor, y una herramienta que la toma por ti te la roba.

Cuándo NO lo necesitas. OpenTelemetry completo con colector propio es sobrecoste para un servicio pequeño donde las métricas de la 07-04 y unos logs estructurados bastan. Empieza por las cuatro señales de oro y añade trazas cuando tengas un problema de latencia distribuida que no sepas explicar.

Cómo leer "lastre". No significa mala herramienta: significa que en ese tamaño el coste de operarla supera al beneficio. Vault en un equipo de tres no es un Vault pequeño; es un Vault entero mantenido por gente que también escribe el producto. La complejidad no escala hacia abajo.

Tres preguntas. Si alguna no tiene respuesta, la herramienta no entra.

1. ¿Qué problema medido resuelve?

Medido es la palabra clave. No "mejora la seguridad" sino "el mes pasado perdimos 6 horas rotando un secreto filtrado, y esto lo habría evitado". Si no puedes citar un incidente, un tiempo perdido o una métrica que empeora, no tienes un problema: tienes curiosidad. La curiosidad es legítima —explórala en un proyecto personal, no en el pipeline de producción—.

2. ¿Quién la mantiene?

Doble pregunta. Fuera: ¿quién desarrolla el proyecto? ¿Una empresa, una fundación, una persona? ¿Cuándo fue el último commit? Un proyecto CNCF graduated (08-02) es una apuesta muy distinta a un repositorio personal con doce estrellas. Dentro: ¿quién de tu equipo la mantiene cuando falle un viernes? Si la respuesta es "el que la trajo", tienes un factor bus de uno sobre una pieza del camino a producción.

3. ¿Qué pasa si la quitamos?

Si la respuesta es "nada grave", no debería haber entrado. Si es "no podemos desplegar", necesitas un plan de salida antes de adoptarla: cómo se sale, cuánto cuesta, qué datos hay que migrar. Las herramientas se adoptan en una tarde y se abandonan durante años.

Y una cuarta, opcional pero muy reveladora: ¿podríamos conseguir el 80 % del beneficio con 20 líneas de script? Con sorprendente frecuencia, sí. Un grep en un paso del workflow sustituye una política de OPA para una sola regla. Una plantilla de repositorio sustituye a Backstage al principio. La respuesta no siempre es "usa el script", pero la pregunta te obliga a nombrar qué aporta la herramienta más allá de lo obvio.

• Adoptar por moda y no por problema. El error central del módulo. Se reconoce por una señal: no puedes explicar en una frase qué dejará de doler.
• Adoptar varias a la vez. Cuando algo se rompe no sabes cuál fue. Una herramienta cada vez, con al menos dos semanas de uso real antes de la siguiente.
• Confundir "lo usa una empresa grande" con "me sirve". Ellos tienen equipo de plataforma dedicado. Es la señal de alarma de la 08-02 aplicada a las herramientas.
• Meter herramientas lentas en el camino crítico. Mutation testing o k6 en cada PR convierten un CI de 4 minutos en uno de 40, y el equipo empieza a saltárselo. Lo lento va fuera del PR: nocturno, semanal o post-merge (04-04).
• Desplegar políticas en modo bloqueo desde el primer día. Modo aviso primero, siempre. Una política mal escrita bloquea a todo el mundo y quema la idea entera para meses.
• Verificar firmas sin verificar identidad. cosign verify sin --certificate-identity-regexp da una sensación de seguridad falsa. Cualquiera puede firmar.
• Automerge sin confiar en la suite. Renovate con automerge sobre un CI con verde falso automatiza la introducción de fallos.
• Construir la plataforma antes que el camino. Primero la plantilla y el workflow reutilizable; el portal después, y solo si duele.
• Consejo: empieza siempre por los linters del pipeline. Cinco minutos, cero coste, beneficio inmediato. No hay otra herramienta de esta lección con esa relación.
• Consejo: documenta cada adopción en el PIPELINE.md con el formato de la 07-06: qué problema, qué se descartó, qué condición obligaría a revisarlo. Tu yo de dentro de dos años necesita saber por qué está eso ahí.
• Consejo: escribe también los descartes. "Evaluamos Vault en marzo y lo descartamos porque X" ahorra que alguien reabra la discusión cada seis meses.

Para cada situación, decide qué herramienta (o ninguna) de esta lección adoptarías, justifica con las tres preguntas del apartado 12, y di qué descartas y por qué:

a) Equipo de 4 personas, monolito Node.js en ECS, un entorno. Han sufrido dos incidentes en tres meses por credenciales de base de datos rotadas mal: alguien cambia la contraseña en RDS y se olvida de actualizarla en algún sitio. Presupuesto de herramientas: bajo pero no nulo.

b) Equipo de 18 personas, 12 microservicios en Kubernetes, despliegan unas 30 veces por semana. Cuando se publica una vulnerabilidad crítica en una librería popular, tardan entre uno y dos días en saber qué servicios están afectados.

c) Equipo de 6 personas, aplicación web con 400 usuarios internos. El tech lead propone montar Backstage "para que todo esté organizado y porque es lo que se lleva".

Reservalia está hoy donde acabó el módulo 4: 12 despliegues/semana, 3,5 h de lead time, 3,8 % de CFR, 9 min de restore. Equipo de tres. ECS Fargate, GitHub Actions, sin Kubernetes. Diego sigue vigilando cada euro.

Elige tres herramientas de esta lección para adoptar en los próximos seis meses, en orden, y para cada una: qué métrica DORA (o qué otro dolor concreto) pretende mover, cómo se lo justificarías a Diego, y qué señal indicaría que la adopción fue un error.

Elige una herramienta de esta lección que te resulte atractiva y que hayas decidido no adoptar en tu contexto. Escribe la entrada de PIPELINE.md correspondiente, con el formato de la 07-06: qué problema resolvería, por qué se descarta hoy, qué alternativa más barata se usa en su lugar, y la condición concreta y observable que obligaría a reabrir la decisión.

Solución 1

a) Equipo de 4, incidentes por rotación de credenciales.

Adoptar: AWS Secrets Manager, con la aplicación leyendo el secreto por referencia desde la definición de tarea de ECS.

• ¿Qué problema medido? Dos incidentes en tres meses con causa idéntica. La causa raíz no es el descuido: es que el mismo valor vive en tres sitios y la consistencia depende de que alguien recuerde los tres. Es un problema de diseño, y eliminar la duplicación lo elimina.
• ¿Quién la mantiene? AWS. Servicio gestionado, sin operación por parte del equipo. Rotación automática configurable con Lambda si más adelante hace falta.
• ¿Qué pasa si la quitamos? Se vuelve al estado anterior con un cambio en la definición de tarea. Salida barata y sin migración de datos.

Descartado: Vault. Resolvería lo mismo y más, pero exige operar un sistema crítico con cuatro personas que ya están al 100 %. Es exactamente el caso de "lastre" de la tabla del apartado 11.

Descartado: SOPS. Versionaría los secretos, pero no resuelve el problema declarado —la aplicación seguiría leyendo el valor desde la configuración desplegada, y la rotación seguiría siendo un cambio coordinado—.

b) 18 personas, 12 microservicios, uno o dos días para saber si están afectados.

Adoptar: Dependency-Track, alimentado con los SBOM que el pipeline ya debería estar generando con Syft o Trivy.

• ¿Qué problema medido? De 24 a 48 horas de trabajo manual por cada vulnerabilidad crítica publicada. Es tiempo caro de gente cara, es recurrente y —lo más grave— es tiempo durante el cual estás expuesto sin saberlo.
• ¿Quién la mantiene? Proyecto OWASP, con comunidad establecida. Dentro: hay que asignar dueño; con 18 personas es viable.
• ¿Qué pasa si la quitamos? Se vuelve al escaneo por artefacto y a la respuesta manual. Los SBOM siguen generándose, así que la salida no pierde nada.

La clave del razonamiento: su escaneo actual responde "¿esta imagen es segura hoy?" y su problema es el inverso, "¿dónde está esta librería ahora mismo?". Ninguna cantidad de escaneo en el pipeline responde a eso; hace falta inventario.

Complemento razonable: Renovate con agrupación, porque con 12 servicios el ruido de Dependabot es alto y la mayoría de esas vulnerabilidades se cierran actualizando.

c) 6 personas, 400 usuarios internos, propuesta de Backstage.

Ninguna. Rechazar la propuesta, y hacerlo con las tres preguntas en vez de con una opinión:

• ¿Qué problema medido? Ninguno declarado. "Que todo esté organizado" no es un problema: es una aspiración estética. La pregunta que zanja la conversación: ¿cuántas horas hemos perdido en los últimos tres meses buscando quién es el dueño de un servicio, o montando un servicio nuevo? Con seis personas, la respuesta será cercana a cero, porque el catálogo cabe en una conversación.
• "Porque es lo que se lleva" es literalmente la señal de alarma de la 08-02 y el antipatrón central de esta lección.
• ¿Qué pasa si lo quitamos? Nada. Que la respuesta sea "nada" antes siquiera de adoptarlo es la prueba de que no debe entrar.

Contrapropuesta constructiva, porque rechazar sin alternativa suele fracasar: si lo que de verdad molesta es la inconsistencia entre servicios, el 80 % del beneficio está en una plantilla de repositorio con el pipeline ya montado y un CODEOWNERS bien mantenido (02-07, 04-05). Coste: una tarde. Y si dentro de un año hay 30 servicios y gente perdiéndose, Backstage entra con un problema medido detrás.

Solución 2

Hay varias combinaciones defendibles. Esta prioriza coste cero, riesgo bajo y beneficio verificable, que es lo que el contexto de Reservalia exige.

Primera: los linters del pipeline (actionlint, hadolint, shellcheck, tflint). Mes 1.

• Qué mueve: lead time. Cada iteración de prueba y error con YAML de Actions cuesta un ciclo completo de CI. actionlint los detecta en segundos, en local y en el PR.
• A Diego: coste cero en euros, unos 15 segundos de CI, y una tarde de configuración. El argumento que le convence es de minutos de runner: menos ejecuciones fallidas por errores de sintaxis es literalmente menos gasto.
• Señal de error: si genera avisos que el equipo silencia sistemáticamente, la configuración está mal calibrada, no la herramienta. Se ajustan reglas, no se quita.

Segunda: Testcontainers para las pruebas de integración. Meses 2-3.

• Qué mueve: tasa de fallo de cambios (3,8 %). Los fallos que llegan a producción en un sistema con buena cobertura unitaria suelen venir de la frontera con la base de datos: restricciones, transacciones, comportamiento de PostgreSQL que ningún doble reproduce. Y de paso reduce el tiempo de restauración, porque son fallos que se detectan antes.
• A Diego: gratis, y el argumento es de coste evitado. Un incidente de producción en Reservalia cuesta más en tiempo de las tres personas que todo el CI del mes. Se puede cuantificar mirando los últimos tres incidentes y preguntando cuántos habría cazado un test contra PostgreSQL real.
• Señal de error: si el CI se alarga más de dos minutos y no aparece ningún fallo capturado en tres meses, sobra. Se mide antes y después.

Tercera: k6 con thresholds, tras el despliegue a staging, no en cada PR. Meses 4-6.

• Qué mueve: tasa de fallo y tiempo de restauración, en el modo de fallo que peor lleva Reservalia: la degradación gradual. Un endpoint que pasa de 200 ms a 900 ms no rompe ningún test y no dispara ninguna alerta hasta que el SLO empieza a consumirse. Es exactamente lo que apareció en la 07-04.
• A Diego: gratis, ejecutado una vez por despliegue a staging, unos 2 minutos fuera del camino crítico del PR. Y el argumento de negocio es fuerte: la ventana crítica de las reservas es donde más carga hay y donde una caída cuesta clientes —la restricción 3 del encargo de la 07-06—.
• Señal de error: si los umbrales fallan constantemente por ruido del entorno de staging y la gente empieza a reintentar el job sin mirar, el problema es el entorno o los umbrales. Un umbral que se ignora es peor que no tenerlo, porque enseña al equipo a ignorar puertas.

Descartados explícitamente y por qué: Vault (lastre para tres personas), GitOps y entrega progresiva (exigen Kubernetes; Reservalia está en ECS), Backstage (sin problema medido), políticas como código (con tres personas las reglas caben en la revisión; si alguna es crítica, un grep en el workflow basta), mutation testing (interesante, pero la prioridad es que los tests capturen fallos reales antes de refinar los que ya hay).

Solución 3

Ejemplo, sobre entrega progresiva automatizada:

Lo que hace válida esta entrada no es el descarte, sino que la condición de revisión sea observable y no opinable: "500 peticiones por minuto" se comprueba en Grafana; "cuando tengamos más tráfico" no se comprueba nunca y garantiza que la discusión se reabra cada seis meses sin datos nuevos.

Este módulo entero se ha ordenado por una idea que conviene dejar dicha con claridad: una herramienta es una respuesta, y solo tiene sentido si existe la pregunta. Todas las de esta lección son buenas; ninguna es buena para todos.

Lo esencial:

• Secretos: el mejor secreto es el que no existe (OIDC, roles). Cuando la aplicación necesita secretos en ejecución, el gestor de la nube es la respuesta sensata; Vault entra con varias nubes o requisitos de auditoría; SOPS+age es una opción infravalorada para versionar configuración cifrada.
• Entrega progresiva y GitOps resuelven problemas reales de la 03-04 y la 03-02, pero exigen Kubernetes y, en el caso del canary automático, tráfico suficiente para que las métricas signifiquen algo.
• Políticas como código convierten reglas de revisión en verificaciones automáticas: valiosas a partir de varios equipos, sobrecoste antes, y siempre desplegadas primero en modo aviso.
• Los linters del pipeline son la única recomendación sin contrapartida de toda la lección. Cinco minutos, cero euros, beneficio inmediato.
• Cadena de suministro: SLSA da el vocabulario para decir dónde estás; verificar firma con identidad es lo que hace que firmar sirva; y el inventario de SBOM responde la pregunta que rompe empresas, que no es "¿es segura esta imagen?" sino "¿dónde está esta librería ahora?".
• Pruebas: Testcontainers acerca las pruebas a la realidad, k6 convierte el rendimiento en puerta, y el mutation testing es la respuesta honesta a la mentira de la cobertura — es verificar por el lado negativo, automatizado.
• Plataforma interna: primero el golden path, después el portal. Una plataforma sin usuarios es un proyecto de vanidad.
• Y el criterio, que vale más que el catálogo: ¿qué problema medido resuelve?, ¿quién la mantiene dentro y fuera?, ¿qué pasa si la quitamos? Más la cuarta, incómoda y reveladora: ¿bastarían veinte líneas de script?

La tabla de adopción por tamaño dice algo que merece repetirse: la complejidad no escala hacia abajo. Vault en un equipo de tres no es un Vault pequeño. Backstage con seis servicios no es un Backstage ligero. Copiar la arquitectura de una empresa de quinientas personas sin tener sus problemas te deja con sus costes y sin sus beneficios.

Ya tienes el fundamento (08-01), el contexto (08-02) y el catálogo (08-03). Falta la pregunta que ninguno de los tres responde: ¿hacia dónde vas tú? Qué sabes hacer ahora y qué no, en qué dirección profundizar, qué certificaciones sirven de algo y cuáles no, cómo demostrar lo que sabes sin un papel, y cómo mantenerse al día sin quemarse.

Esa es la última lección del curso: 08-04, Ruta de Aprendizaje, Certificaciones y Próximos Pasos.