¿Qué comprobaciones previas al despliegue han detenido realmente una versión defectuosa en el último año, y cuáles nunca se han activado?

Pregunta abierta

Una canalización (pipeline) de versiones acumula controles con el tiempo: pruebas unitarias y de integración, una comprobación de reproducibilidad de la compilación, un escaneo de contenedores, una prueba de humo tras el despliegue, una comparación canario, una aprobación manual y un plazo de despliegue. La documentación de Deployment de Kubernetes, por ejemplo, describe progressDeadlineSeconds e indica que Kubernetes no toma ninguna acción sobre un Deployment estancado más allá de reportar una condición ProgressDeadlineExceeded; algo más tiene que actuar sobre ello. Cada control cuesta tiempo en cada versión y, ocasionalmente, bloquea una buena. Lo que falta en el wiki es evidencia sobre qué controles se han ganado su lugar: a lo largo de un año de versiones, ¿qué controles detuvieron una versión que habría causado un incidente, cuáles nunca se activaron en absoluto, y cuáles solo se activaron por falsos positivos que se anularon? ¿Los equipos mantienen un registro que les permita responder esto, o el recuerdo de «ese control nos salvó una vez» es la única evidencia? ¿Y es distinta la respuesta para los controles que se ejecutan antes de compilar el artefacto, los que se ejecutan en un entorno de staging y los que observan el despliegue en producción?

La pregunta no es si los controles son buenos en principio, sino cuáles, para un tipo de servicio dado, tienen un historial comprobado, de modo que un equipo pueda dedicar el tiempo de su canalización a donde efectivamente ha detenido algo.

Qué contiene una respuesta útil

El tipo de servicio, la frecuencia de versiones y el mecanismo de despliegue. La lista de controles con, por cada uno, el número de versiones en el período, el número de bloqueos, cuántos bloqueos se juzgaron después verdaderos positivos, y cuántos se anularon. Para cada verdadero positivo, qué habría llegado a los usuarios y cómo lo detectó el control. Para los controles que nunca se activaron, si el equipo los eliminó, los mantuvo como seguro, o descubrió que estaban mal configurados (una comprobación que no podía fallar). Cómo se mantuvo el registro: registros (logs) de la canalización, un campo de revisión de incidentes, o reconstrucción de memoria, ya que esto determina cuánto confiar en los recuentos. Si el umbral de un control se ajustó durante el período, y si un control que se activó era realmente uno que se había añadido tras un incidente. Los informes sobre controles que estuvieron silenciosamente rotos durante meses son tan valiosos como los informes sobre controles que funcionaron.