Escribe el memorando de lanzamiento o no lanzamiento

1512. Identidad de la lección

Módulo

4.1 — Ingeniería de lanzamiento

Lección

Escribe el memorando de lanzamiento o no lanzamiento

Tipo académico

Integración

Tipo de esquema

Práctica

Orden

3 del módulo

Tiempo estimado

45–60 minutos

Esta lección integra puertas de lanzamiento, revisión de evidencias, seguimiento mediante revisiones inmutables, tratamiento de riesgos y comunicación de decisiones. Elaborarás un memorando breve para una compilación candidata concreta.

1513. Objetivo de aprendizaje

Al terminar esta lección, podrás redactar un memorando de lanzamiento o no lanzamiento que identifique una candidata mediante una referencia inmutable, la compare con el último punto de control conocido como bueno, distinga entre bloqueos, riesgos aceptados y evidencia faltante, aplique los umbrales definidos previamente y deje constancia de quién autorizó cada riesgo aceptado.

1514. Por qué importa

Una puerta de lanzamiento indica qué debe comprobarse; el memorando registra la decisión que se toma a partir de esas comprobaciones. Así se evita que una frase vaga como “parece listo” se convierta en una decisión sin documentar.

La decisión debe vincularse con la candidata exacta que se evaluó. Una rama o una etiqueta de Git ordinaria puede cambiar, por lo que su nombre no siempre identifica el contenido evaluado. Es preferible usar el SHA completo de un commit o un identificador de artefacto asociado a ese SHA. Las ramas y etiquetas sirven como contexto, salvo que el proceso de lanzamiento garantice y documente que son inmutables.

El memorando también debe distinguir tres situaciones:

• Bloqueo: se incumple un umbral o una condición obligatoria impide el lanzamiento.
• Riesgo aceptado: una incidencia o limitación conocida se permite conforme a una política vigente o por decisión de una autoridad identificada, después de revisar su impacto y la evidencia.
• Evidencia faltante: una comprobación obligatoria no se ha ejecutado o no ofrece un resultado concluyente, de modo que la puerta todavía no respalda el lanzamiento.

Aceptar un riesgo no equivale a aprobar una comprobación. Tampoco se puede eludir una puerta obligatoria rebajando o reescribiendo su umbral después de revisar la evidencia. Si se permite una excepción, el memorando debe citar la autoridad o la política que la autoriza.

1515. Conocimientos previos

Ya deberías poder:

• identificar la revisión candidata y el alcance de una comprobación de lanzamiento;
• definir la evidencia, el responsable y la condición de preparación de una puerta;
• distinguir entre resultados fallidos, no ejecutados e inconcluyentes;
• utilizar los campos de la puerta creada en Construye una puerta de lanzamiento, dentro del módulo 4.1.

1516. Concepto central

Una decisión de lanzamiento defendible es una afirmación basada en umbrales sobre una candidata identificada, no una impresión general sobre el proyecto.

Un buen memorando responde siete preguntas:

1. ¿Qué compilación se evalúa y qué revisión o artefacto inmutable la identifica?
2. ¿Qué último punto de control conocido como bueno sirve de línea base?
3. ¿Qué cambió desde esa línea base y qué comprobaciones se repitieron a causa de esos cambios?
4. ¿Qué umbrales se aplican y qué evidencia respalda cada resultado?
5. ¿Qué está bloqueado, ha fallado, no se ha ejecutado o sigue siendo inconcluyente?
6. ¿Qué riesgos conocidos se aceptan, quién los acepta, con qué autoridad o política y bajo qué condición de seguimiento?
7. ¿Qué decisión se desprende de todo ello y qué evidencia o corrección permitiría reconsiderarla?

Si eliges Esperar evidencia, regístralo como un estado de no lanzamiento. La candidata no puede lanzarse hasta obtener la evidencia obligatoria y reconsiderar la decisión.

1517. Modelo mental: Registro de decisión

La cadena de razonamiento es:

candidata inmutable → línea base y cambios → umbrales vigentes → estados de la evidencia → bloqueos o riesgos aceptados → decisión → condición para reconsiderar

No modifiques un umbral obligatorio solo porque la candidata no lo cumple. Cambiar una puerta es una decisión de gobierno aparte y no puede convertir de forma retroactiva un fallo o una falta de evidencia en un resultado aprobado.

1518. Ejemplo resuelto

Supón que la compilación candidata CB-07 corresponde al artefacto artifact-CB-07, asociado en el registro de compilación al SHA completo 8f31c2a4e6b7d941ac78157b24575a199cd99310. La rama release/cb-07 se anota únicamente como contexto. El último punto de control conocido como bueno es 6a20b19d67001bd062a30b599728dc38ce6654f4.

La puerta exige:

• completar el recorrido principal sin defectos bloqueantes;
• iniciar correctamente la compilación desde un entorno objetivo limpio;
• disponer de evidencia registrada para cada comprobación obligatoria.

Comparación con la línea base

Desde el último punto conocido como bueno, la candidata modifica la configuración de arranque y sustituye recursos visuales de un menú. Como cambió el arranque, debe repetirse la prueba en un entorno limpio. Como cambiaron los recursos del menú, también deben repetirse las comprobaciones pertinentes de presentación y navegación. Aunque el recorrido principal no cambió, se repitió como prueba de regresión y se completó dos veces.

Resultados disponibles:

• recorrido principal: verificado, con dos ejecuciones registradas para el SHA candidato;
• arranque en entorno limpio: no ejecutado;
• navegación del menú: verificada;
• desalineación de una etiqueta del menú: incidencia conocida y verificada, limitada a una etiqueta y asignada a la persona responsable de la interfaz.

La incidencia visual solo puede proponerse como riesgo aceptado si el memorando indica su impacto, cita la evidencia, identifica al responsable, señala la autoridad o política que permite aceptarla y define una condición de seguimiento. Calificarla sin más como “no bloqueante” no es suficiente.

Aunque la incidencia visual se acepte correctamente, la prueba de arranque en un entorno limpio sigue siendo obligatoria y no se ha ejecutado. No se puede eliminar ese requisito cambiando su umbral después de revisar los resultados.

Una conclusión defendible sería:

Decisión: no lanzar artifact-CB-07 por ahora. El artefacto está asociado al commit 8f31c2a4e6b7d941ac78157b24575a199cd99310. Frente a la línea base 6a20b19d67001bd062a30b599728dc38ce6654f4, cambiaron la configuración de arranque y los recursos del menú. Se repitieron y aprobaron las comprobaciones del recorrido principal y de navegación, pero no se ejecutó la prueba obligatoria de arranque en un entorno limpio. La desalineación del menú puede tratarse por separado como riesgo aceptado únicamente mediante la autoridad o política documentada. La evidencia faltante mantiene esta candidata en estado de no lanzamiento. La decisión podrá reconsiderarse cuando se registre el resultado del arranque para el mismo commit; si cambia la candidata, habrá que crear un nuevo registro.

Esta conclusión no predice un fallo. Se limita a afirmar que falta evidencia obligatoria.

1519. Flujo de trabajo con IA

Usa la IA para organizar los registros aportados y detectar afirmaciones sin respaldo, no para tomar la decisión.

1. Reúne el registro del artefacto, el SHA completo, la rama o etiqueta de contexto, la línea base, los cambios, las puertas, las notas de prueba, las incidencias abiertas y la política de riesgos aplicable.
2. Pide a la IA que clasifique únicamente el material proporcionado como verificado, fallido, no ejecutado, inconcluyente o posible riesgo aceptado.
3. Contrasta cada clasificación con los registros originales y elimina las inferencias sin respaldo.
4. Para cada posible riesgo aceptado, exige impacto, evidencia, responsable, autoridad o política y condición de seguimiento.
5. Aplica tú los umbrales y redacta la decisión final.
6. Pide a la IA que señale las frases que no indiquen una fuente de evidencia, una candidata, un umbral o una base de autorización.

La IA no puede convertir una comprobación no ejecutada en evidencia, autorizar un riesgo ni decidir que un umbral obligatorio ha dejado de aplicarse.

1520. Flujo de trabajo con Git y artefactos

1. Registra el identificador de la compilación candidata.
2. Registra el SHA completo o un identificador de artefacto asociado a ese SHA.
3. Anota las ramas o etiquetas solo como contexto, salvo que exista una garantía documentada de inmutabilidad.
4. Registra una revisión inmutable o un punto de control controlado como último estado conocido como bueno.
5. Identifica qué cambió entre la línea base y la candidata.
6. Confirma que cada evidencia corresponde a la candidata identificada.
7. Si cambia la candidata, crea un nuevo registro de decisión en lugar de reutilizar el anterior.

1521. Práctica guiada

Redacta un memorando de 150–250 palabras para CB-07 o para una candidata que tengas autorización para evaluar.

Memorando de decisión de lanzamiento
Compilación o artefacto candidato:
SHA completo asociado a la candidata:
Rama o etiqueta de contexto:
Último punto de control conocido como bueno:
Cambios desde la línea base:
Comprobaciones repetidas a causa de esos cambios:
Decisión: Lanzar / No lanzar / Esperar evidencia (no lanzar hasta reconsiderar)
Alcance:
Umbrales obligatorios:
Evidencia verificada:
Evidencia fallida, no ejecutada o inconcluyente:
Bloqueos:
Riesgos aceptados y justificación:
- Riesgo e impacto:
- Evidencia de respaldo:
- Responsable:
- Autoridad aprobadora o política definida:
- Condición de seguimiento:
Razonamiento:
Condición para reconsiderar la decisión:
Responsable y siguiente acción:

Completa el ejercicio en seis pasadas:

1. Identifica la candidata de forma inmutable. Usa un SHA completo o un artefacto asociado a él. Añade la rama o etiqueta solo como contexto.
2. Compara con la línea base. Explica qué cambió y qué pruebas se repitieron como consecuencia.
3. Aplica los umbrales vigentes. No rebajes ni reescribas un requisito después de ver los resultados.
4. Clasifica la evidencia. Mantén separados los resultados verificados, fallidos, no ejecutados e inconcluyentes.
5. Trata los riesgos conocidos. Para cada riesgo aceptado, documenta impacto, evidencia, responsable, autoridad o política y condición de seguimiento. Si falta alguno de esos elementos, no lo presentes como aceptado.
6. Registra la decisión. Indica qué umbral la determina y qué permitiría reconsiderarla.

1522. Validación / evidencia

1523. Ideas clave

• Vincula la decisión con un SHA completo o un artefacto asociado a ese SHA.
• Compara los cambios y las pruebas pertinentes con el último punto conocido como bueno.
• Mantén separados los bloqueos, los riesgos aceptados y la evidencia faltante.
• Un riesgo aceptado exige impacto, evidencia, responsable, autoridad o política y seguimiento.
• No se puede eludir una puerta obligatoria reescribiendo su umbral después de revisar los resultados.
• “Esperar evidencia” sigue significando no lanzar hasta reconsiderar la decisión.

1524. Comprobación de conocimientos

1525. Siguiente lección

Este registro de decisión cierra la secuencia de ingeniería de lanzamiento. Continúa con 4.2 — Live ops, empezando por Live ops es un modelo operativo, donde distinguirás las operaciones continuas del mantenimiento ordinario posterior al lanzamiento.

1526. Comprobación