Sala 5 · la solicitud de cambio que llegó como código

Una política de dos personas distintas busca que nadie pueda cambiar producción solo. Para contar las aprobaciones válidas hay que sacar la del autor y contar cada persona una sola vez, aunque haya vuelto a aprobar tras una nueva versión. Quien pidió cambios no aprobó.

El diff muestra lo que cambia, línea a línea, y es lo más rápido de revisar: un valor de origen que pasa de una red concreta a todo Internet cambia el alcance de una regla en una sola línea, y es fácil de pasar por alto entre ajustes de capacidad y de versión.

El plan muestra qué hará la herramienta antes de hacerlo. Modificar un recurso en sitio suele ser inocuo; destruirlo y crearlo de nuevo implica que, mientras se rehace, el servicio que lo usa no está, y que lo que no esté respaldado se pierde. Es lo primero que se mira en un plan sobre un recurso con datos.

Para dimensionar el riesgo y la ventana de un cambio se cuentan los recursos que de verdad se tocan, solo en el entorno afectado: un recurso listado con «sin cambios» está en el plan para dar contexto, y los de otros entornos no cuentan para producción.

Las verificaciones automáticas son la parte de la política que no depende de que alguien se acuerde: formato, sintaxis, política, secretos y plan adjunto. La solicitud no debería fusionarse con una en rojo, aunque tenga aprobaciones; y la que falla suele ser la que explica el problema de fondo.