Decide una publicación con pruebas

Formula la decisión con precisión

Un pipeline verde aporta pruebas de un conjunto de comprobaciones. No describe por completo la decisión de publicación. La persona responsable necesita saber qué cambiará, dónde y qué consecuencias quedan.

Para una exportación ficticia de clientes, identifica el commit aceptado y el artefacto producido a partir de él. Indica el entorno de destino. Enlaza las pruebas, la revisión y cualquier excepción aprobada. Incluye los cambios de datos o infraestructura que acompañan a la aplicación.

El SSDF de NIST aporta prácticas de desarrollo seguro, mientras la procedencia de SLSA ayuda a describir cómo se produjo un artefacto. Ninguno elimina la necesidad de decidir si esta publicación es adecuada para este servicio. NIST SSDF, procedencia en SLSA.

Separa tres eventos

El merge incorpora un cambio de código a una rama. El despliegue coloca un artefacto en un entorno. La activación de una función pone su comportamiento a disposición de los usuarios. Estos eventos pueden coincidir, pero no son necesariamente el mismo evento.

Un servicio puede desplegar una función inactiva y activarla más tarde. Una migración de base de datos puede afectar a producción antes de que aparezca una función visible. Define la secuencia real en vez de suponer que hacer merge de una PR describe todas las consecuencias.

Para la exportación, una feature flag puede limitar la exposición inicial. No protege automáticamente un endpoint nuevo ni revierte una migración de esquema. Verifica el control en el punto donde se produce la consecuencia.

Revisa un registro breve de pruebas

Usa un registro que otra persona responsable pueda inspeccionar:

• Propósito y usuarios afectados.
• Identidad del commit y del artefacto.
• Comprobaciones pertinentes de comportamiento, seguridad y compatibilidad.
• Entorno de destino e identidad de ejecución.
• Excepciones restantes con responsables y condiciones de caducidad.
• Monitorización, método de recuperación y responsable de respuesta.

Mantén concretas las afirmaciones. «Las pruebas pasaron» aporta menos que un enlace a los resultados del commit de publicación con una descripción clara de cobertura. «Hay rollback» aporta menos que un procedimiento probado con límites explícitos.

Decide cómo detener la publicación

Define las condiciones de publicación antes de ejecutar. En la exportación ficticia, detén la publicación si funciona el acceso entre organizaciones, si el artefacto difiere del resumen criptográfico aceptado o si la recuperación no está disponible. Son condiciones ilustrativas, no una lista universal.

Después del despliegue, inspecciona las señales relevantes para los usuarios. Compara los errores y los tiempos de respuesta con los objetivos aceptados del servicio. Un proceso en buen estado no demuestra que funcione el flujo del usuario.

Si falla una condición, aplica la respuesta acordada. Puede consistir en desactivar la función, revertir código compatible o recuperar datos. Elige la acción que resuelva el fallo sin crear otro mayor.

Conserva la decisión después de publicar

Registra el artefacto realmente desplegado y el resultado. Si la ejecución difiere del plan, haz visible esa diferencia. Incorpora los incidentes y el trabajo inesperado al diseño de la siguiente publicación.

Un sistema automatizado de entrega debe facilitar la inspección de este registro. No debe exigir que quien revise reconstruya la publicación a partir de chats, logs y capturas desconectados. Las pruebas claras permiten automatizar el trabajo rutinario y conservar decisiones con responsables.