Todo proyecto de software tiene un momento traicionero: aquel en que alguien dice “está listo” y todavía no está en línea. Entre uno y otro caben una revisión olvidada, una variable que nadie configuró y una publicación hecha a mano un viernes por la noche.
La cadena existe para que ese intervalo no dependa de que nadie se acuerde de nada.
El punto de partida
Sigamos un cambio ficticio, pero muy típico: el cliente quiere que el formulario de contacto acepte teléfonos con prefijo internacional. La issue dice qué tiene que ser verdad al final — el campo acepta números de otros países y sigue rechazando lo que no es un teléfono.
Un agente toma la issue, trabaja en una copia aislada del repositorio y entrega un merge request a la rama de integración. Hasta aquí, nada se ha publicado. Y nada se publicará sin pasar por el resto.
Las puertas, en orden
Todo merge request atraviesa la misma secuencia. La configuración se parece a esta:
stages: [verificar, revisar, publicar, confirmar]
tipos-y-pruebas:
stage: verificar
script:
- bun install --frozen-lockfile
- bun run check
- bun test
secretos:
stage: verificar
script:
- gitleaks detect --no-banner
publicar:
stage: publicar
rules:
- if: $CI_COMMIT_BRANCH == "staging"
script:
- ./deploy.sh
confirmar:
stage: confirmar
script:
- ./smoke.shCada etapa tiene un papel distinto, y ninguna sustituye a otra:
| Etapa | Lo que garantiza |
|---|---|
| Verificar | el código compila, las pruebas pasan y no se filtró ningún secreto |
| Revisar | alguien que no escribió el código confirma que entrega el pedido |
| Publicar | la versión aprobada sale en línea sin intervención manual |
| Confirmar | lo que está en línea es, de hecho, la versión nueva — y responde |
La revisión no la hace el mismo agente
El agente que escribió el código no aprueba su propio trabajo. La revisión la hace otro agente, con otras instrucciones, cuyo único objetivo es encontrar lo que no está bien: criterios de aceptación a medias, comportamiento roto, fallas de seguridad.
Si la revisión reprueba, el trabajo vuelve con el motivo escrito. Si aprueba, ocurre el merge — y solo entonces empieza la publicación.
Publicado no es lo mismo que en línea
Este es el detalle que la mayoría de las cadenas ignora. Que el comando de publicación termine sin error no prueba nada. Puede haber subido la versión vieja otra vez. Puede haber subido la nueva y que no esté respondiendo.
Por eso la última etapa confirma el efecto: el servicio que está corriendo fue realmente reemplazado, y la versión nueva responde como debe. Si no, la cadena se pone en rojo y nos enteramos antes que el cliente.
Un pipeline en verde no prueba el efecto. El efecto se prueba mirando el efecto.
¿En cuánto tiempo?
En un cambio pequeño como el del teléfono, la cadena completa tarda pocos minutos. El número exacto importa menos que el hecho de que siempre es el mismo camino: el cambio de una línea y el de mil líneas atraviesan las mismas puertas.
Eso es lo que permite entregar muchas veces al día sin que ninguna sea un salto al vacío.