En 05-02 desplegamos servicio-pedidos en Kubernetes escribiendo kubectl apply a mano. Es exactamente lo que TechCorp no puede permitirse: con seis servicios y un gateway, cada uno desplegando varias veces por semana, la mano humana es lenta, inconsistente y la fuente de los "despliegues de jueves noche con reversiones" del módulo 1. La integración continua (CI) hace que cada cambio se pruebe automáticamente en minutos; el despliegue continuo (CD) lleva lo que pasa las pruebas hasta producción sin intervención. Esta lección construye el pipeline de servicio-pedidos con GitHub Actions: pruebas unitarias, de integración con Testcontainers y de contrato con Pact (04-05), construcción y publicación de la imagen de 05-01, can-i-deploy como puerta, actualización de los manifiestos Kustomize de 05-02 y despliegue con GitOps. Al final aplicamos la regla de Luis para que los otros cinco servicios no copien 150 líneas de YAML, y medimos el resultado con las métricas DORA. Cómo cambiar de versión sin cortar el servicio es de 05-04.

1. Qué cambia el CI/CD con microservicios
2. Las etapas del pipeline de TechCorp
3. .github/workflows/ci.yml de servicio-pedidos, línea a línea
4. Pruebas de contrato en el pipeline: Pact Broker y can-i-deploy
5. Despliegue continuo: .github/workflows/cd.yml
6. GitOps con Argo CD: techcorp/plataforma como fuente de verdad
7. Versiones, etiquetas y changelogs por servicio
8. Entornos y promoción: dev → staging → prod
9. Secretos en CI
10. El pipeline de @techcorp/comun-http
11. La regla de Luis: un workflow reutilizable para los seis servicios
12. Métricas DORA: medir el pipeline

El monolito techcorp-shop tenía un pipeline: 40 minutos de suite, un artefacto, un despliegue coordinado. Con microservicios:

La independencia de despliegue es la promesa central de la arquitectura (01-02, 02-01) y solo se cumple si el pipeline de cada servicio puede desplegar solo, sin un "tren de releases" que agrupe a todos. La condición para atreverse es la confianza que dan las pruebas de contrato: es Pact, no una prueba E2E de todo el sistema, quien responde "¿romperé a alguien?".

Todo lo anterior a la imagen es CI: rápido, en cada cambio. Lo posterior es CD.

Notas de lectura:

• Dos jobs (pruebas, imagen) con needs: la imagen solo se construye si todo pasa; en un PR (pull_request) solo corre pruebas.
• ubuntu-latest trae Docker, así que test:integracion funciona tal cual: Testcontainers descarga postgres:16 y rabbitmq:3-management en el runner. Es la razón por la que en 04-05 separamos test (sin Docker) de test:integracion.
• docker/metadata-action produce las dos etiquetas de 05-01 sin scripts a mano: sha-<commit> siempre, y la semver cuando el evento es un tag v1.0.1.
• secrets: npmrc= en build-push-action alimenta el --mount=type=secret,id=npmrc del Dockerfile: el token no queda en ninguna capa.
• cache-from/to: type=gha guarda las capas en la caché de GitHub Actions: un cambio en src/ no repite npm ci en CI, igual que en el portátil.
• permissions mínimos: contents: read para clonar, packages: write para publicar. Nada de tokens personales.

En 04-05 el fichero de pacto viajaba a mano de servicio-pedidos a servicio-catalogo. En CI viaja por el Pact Broker (autoalojado o PactFlow), que guarda cada pacto con la versión (github.sha) y la rama del consumidor, y cada resultado de verificación con la versión del proveedor:

En el CI del proveedor (servicio-catalogo), el test:contrato de 04-05 se ejecuta con pactBrokerUrl en lugar de pactUrls, con publishVerificationResult: true y providerVersion: process.env.GITHUB_SHA, y tras desplegar registra en qué entorno está cada versión (pact-broker record-deployment --environment staging). Con eso, la puerta antes de desplegar es una línea:

can-i-deploy responde "sí" solo si todas las versiones de proveedores actualmente desplegadas en staging han verificado con éxito los pactos de esta versión de Pedidos (y, si Pedidos fuera proveedor de alguien, si sus consumidores desplegados siguen satisfechos). Es la garantía de integración a coste de una consulta HTTP: la razón por la que la única E2E de TechCorp puede seguir siendo una.

El despliegue a staging es directo desde el workflow: actualiza la etiqueta de imagen en el overlay de Kustomize (05-02), lanza el Job de migraciones, aplica y espera al rollout, y ejecuta la E2E.

Dos detalles frente a 05-02: el Job de migraciones pasa a llamarse servicio-pedidos-migraciones a secas y el workflow borra el anterior antes de aplicar (un Job es inmutable); es la alternativa al nombre versionado, y funciona porque migrar.js es idempotente. Y kustomize edit set image modifica la línea images: que dejamos preparada en el overlay: el YAML sigue siendo la fuente de verdad, el pipeline solo cambia una etiqueta. Con Helm el equivalente sería helm upgrade --set image.tag=$ETIQUETA.

rollout status es lo que convierte "he aplicado" en "está desplegado y listo": espera a que las réplicas nuevas pasen el readinessProbe y falla (y el job falla) si en 180 s no lo consiguen. Qué hace Kubernetes mientras tanto con las réplicas viejas es 05-04.

Para producción, TechCorp no quiere que un workflow con un kubeconfig en un secreto ejecute kubectl apply contra el clúster de producción. Adopta GitOps: el estado deseado de producción es lo que hay en git (techcorp/plataforma, rama main, overlays/prod), y un agente dentro del clúster (Argo CD; Flux es equivalente) lo lee y lo aplica continuamente.

Por qué TechCorp lo adopta: (1) auditoría: cada despliegue a producción es un commit revisable en plataforma; (2) sin credenciales del clúster fuera del clúster: Argo CD hace pull, nadie hace push; (3) detección de desviaciones: si alguien hace kubectl scale a mano un viernes, Argo lo devuelve al estado de git (o avisa); (4) rollback = revertir el commit. El Job de migraciones se anota como argocd.argoproj.io/hook: PreSync con hook-delete-policy: BeforeHookCreation, que es la forma GitOps de "borrar el anterior y ejecutar antes del Deployment". Argo CD y Flux también pueden desplegar en staging; TechCorp empieza con el workflow directo en staging para aprender y con GitOps en producción, y unificará más adelante.

• Semver por servicio: servicio-pedidos 1.0.1 no tiene nada que ver con servicio-catalogo 1.4.2. Mayor = cambio incompatible de contrato (que en 03-06 significa /v2/), menor = funcionalidad compatible, parche = corrección.
• La imagen sha-<commit> se construye siempre; la semver, al etiquetar: git tag v1.0.1 && git push --tags dispara ci.yml con el tag y metadata-action añade 1.0.1 a la misma imagen (mismo digest) que ya pasó por staging como sha-.... No se reconstruye nada para producción.
• Changelog: CHANGELOG.md en cada repositorio, alimentado a mano o generado a partir de mensajes de commit con la convención conventional commits (feat:, fix:, feat!:), que herramientas como semantic-release o release-please usan para calcular la versión y publicar la release automáticamente. TechCorp adopta la convención de mensajes; la automatización de la versión queda como paso siguiente.

Los tres entornos aplican la misma base Kustomize con overlays distintos (05-02): lo único que cambia entre staging y prod es la etiqueta de imagen, las réplicas y dos claves de ConfigMap. Promover es abrir un PR en plataforma que cambia newTag en overlays/prod (el workflow lo abre solo con peter-evans/create-pull-request); revisar y fusionar es la aprobación.

• secrets.GITHUB_TOKEN: lo genera GitHub para cada ejecución, con los permissions declarados; sirve para ghcr.io y GitHub Packages sin crear nada.
• Secretos de repositorio/organización (PACT_BROKER_TOKEN, PLATAFORMA_TOKEN) y de entorno (KUBECONFIG_STAGING, ligado al environment: staging, con revisores obligatorios si se quiere).
• OIDC en lugar de claves de larga duración: para hablar con la nube (AWS/GCP/Azure) o con un registro externo, el workflow obtiene un token efímero por identidad federada (permissions: id-token: write + aws-actions/configure-aws-credentials) en vez de guardar una access key en un secreto. Es la práctica recomendada y la que TechCorp usará para el clúster de producción si algún día un workflow necesita tocarlo (con GitOps, no lo necesita).
• Nunca echo de un secreto en los logs; GitHub los enmascara, pero base64 o transformaciones los destapan.

La librería (04-01) tiene su propio workflow, más corto: npm ci, npm test, y en tag v*, npm publish a GitHub Packages:

Cada servicio fija en su package.json la versión que usa ("@techcorp/comun-http": "^2.3.0") y la actualiza cuando quiere, con Renovate/Dependabot abriendo el PR: la librería no obliga a redesplegar a nadie, que era la condición para que existiera (04-01).

"Si se hace más de una vez por servicio, se automatiza antes del segundo." El ci.yml del apartado 3 tiene 80 líneas y sería idéntico en Catálogo, Inventario, Pagos, Notificaciones y Clientes salvo el nombre. GitHub Actions permite un workflow reutilizable (workflow_call) que vive en techcorp/plataforma:

Y en cada servicio, el ci.yml se reduce a:

El workflow reutilizable es a los pipelines lo que @techcorp/comun-http a los servicios: se versiona (@v1), cada servicio adopta la versión nueva cuando quiere, y la plantilla plantilla-servicio-node (04-01) ya trae estas nueve líneas. Un cambio en el pipeline (añadir Trivy, cambiar la versión de una acción) se hace una vez.

Las cuatro métricas DORA (DevOps Research and Assessment) miden si todo lo anterior sirve para algo:

Las dos primeras las da el propio pipeline (fecha del commit, fecha del sync de Argo); las otras dos necesitan la gestión de incidentes de 06-05. Lo importante es la relación entre ellas: desplegar más a menudo con cambios más pequeños baja la tasa de fallo y el MTTR, que es lo contrario de la intuición del jueves noche ("desplegamos poco para arriesgar poco").

• Un pipeline "de sistema" que prueba y despliega todos los servicios juntos. Es el tren de releases del monolito con más YAML. Un pipeline por servicio y contratos como garantía.
• Reconstruir la imagen para producción. Lo que se probó no es lo que se despliega. Etiqueta semver sobre la imagen sha- ya probada.
• can-i-deploy como paso opcional o continue-on-error. Se acaba ignorando. Es una puerta: si dice no, no se despliega.
• kubectl apply sin rollout status. El pipeline está verde y las réplicas nuevas en CrashLoopBackOff.
• Copiar ci.yml entre repositorios. A la tercera versión de una acción, seis PRs idénticos. workflow_call.
• Secretos de larga duración en variables cuando OIDC está disponible; tokens personales de un desarrollador en secretos de la organización (dejan de funcionar cuando se va).
• Consejo: ejecuta el workflow localmente con act para depurar; y guarda en un README de cada repositorio el enlace al workflow reutilizable y a los runbooks, para que "cómo se despliega esto" tenga una respuesta.

Ejercicio 1. El CI de servicio-catalogo (proveedor) debe verificar los pactos que publican sus consumidores. Escribe los pasos del job contrato de su ci.yml (sin repetir checkout/setup-node) y explica qué variables de entorno necesita el Verifier de 04-05 para trabajar con el Broker en lugar de con un fichero local, y por qué debe ejecutar record-deployment tras desplegar.

Ejercicio 2. Un desarrollador de Pagos abre un PR que cambia el payload del evento pago.confirmado. ¿En qué etapa del pipeline de Pagos se detectaría una incompatibilidad con servicio-pedidos, con las herramientas de 04-05, y qué haría falta añadir para que can-i-deploy la bloqueara?

Ejercicio 3. Marta pide que Catálogo y Notificaciones se promocionen a producción automáticamente tras pasar la E2E en staging, pero Pedidos y Pagos requieran aprobación humana. Describe cómo se implementa con lo visto (entornos de GitHub, workflow_call, PR de promoción, Argo CD) sin duplicar el workflow.

Solución 1. Pasos: npm ci → npm run test:contrato con PACT_BROKER_BASE_URL, PACT_BROKER_TOKEN, GIT_COMMIT=${{ github.sha }} y GIT_BRANCH=${{ github.ref_name }} en env; el Verifier de 04-05 usa pactBrokerUrl y pactBrokerToken en lugar de pactUrls, providerVersion: process.env.GIT_COMMIT, providerVersionBranch, publishVerificationResult: true (solo en CI: process.env.CI === 'true') y consumerVersionSelectors: [{ mainBranch: true }, { deployedOrReleased: true }] para verificar tanto los pactos de la rama principal de cada consumidor como los de las versiones desplegadas. Tras desplegar a un entorno, pact-broker record-deployment --pacticipant servicio-catalogo --version $GIT_COMMIT --environment staging le dice al Broker qué versión de Catálogo está en staging: sin ese registro, el can-i-deploy de Pedidos no sabe contra qué proveedor comprobar y responde "no" por falta de información.

Solución 2. En la etapa contrato, pero del lado del consumidor: 04-05 fijó JSON Schema de eventos con Ajv y una prueba de que servicio-pedidos tolera campos nuevos de pago.confirmado; si Pagos quita o renombra un campo (importe → cantidad), lo detecta la prueba de esquema del propio Pagos si el esquema está compartido en contratos/asyncapi.yaml (falla en npm test de Pagos), o, si no, la prueba de eventos de Pedidos cuando actualice el esquema. Para que can-i-deploy lo bloquee haría falta un pacto de mensajes (Pact soporta message pacts: Pedidos declara el mensaje que espera; Pagos lo verifica con un MessageProviderPact que produce el evento real) publicado en el mismo Broker: entonces la relación Pagos→Pedidos aparece como cualquier otra y can-i-deploy la comprueba. Es la evolución natural del JSON Schema de 04-05.

Solución 3. El workflow reutilizable de CD (servicio-node-cd.yml) recibe un input promocion-automatica: boolean. Su último job abre el PR de promoción en techcorp/plataforma (cambio de newTag en overlays/prod); si promocion-automatica es true, el mismo job lo fusiona (gh pr merge --auto), y Argo CD sincroniza; si es false, el PR queda abierto y el CODEOWNERS de k8s/servicio-pedidos/ y k8s/servicio-pagos/ exige la revisión de Luis o del líder de Pagos. Además, el job de producción usa environment: production en GitHub con required reviewers para esos dos servicios. Ningún workflow se duplica: Catálogo llama con promocion-automatica: true, Pedidos con false.

El pipeline de TechCorp convierte cada push en una secuencia automática y por servicio: ci.yml con actions/setup-node@v4 (Node 20, caché npm, GitHub Packages), npm run lint, npm test, npm run test:integracion con Testcontainers en el runner, npm run test:contrato y publicación de pactos en el Pact Broker, docker/build-push-action con etiquetas sha-<commit> y semver hacia ghcr.io/techcorp/servicio-pedidos (con permissions: packages: write y el .npmrc como secreto de build), escaneo con Trivy, y can-i-deploy como puerta; cd.yml que fija la imagen en el overlay de Kustomize (kustomize edit set image), ejecuta el Job de migraciones, hace kubectl apply + rollout status y lanza la E2E contra staging; GitOps con Argo CD y techcorp/plataforma como fuente de verdad para producción; semver y sha- sobre la misma imagen; entornos con los mismos manifiestos; secretos de GitHub y OIDC; el pipeline de @techcorp/comun-http; el workflow reutilizable servicio-node-ci.yml@v1 que aplica la regla de Luis; y las métricas DORA para comprobar que los jueves noche han terminado. Queda una pregunta que rollout status esconde: ¿qué ocurre exactamente con el tráfico mientras las réplicas de la 1.0.0 dejan paso a las de la 1.0.1, y cómo se despliega una versión a un 10 % de los usuarios antes de dársela a todos? Eso es la siguiente lección: estrategias de despliegue.