Dos comités, no uno: autorizar preproducción y producción
Por qué DevGob divide la autorización de cambios en una puerta de preproducción y otra de producción, y qué ve el segundo comité que el primero no puede ver.
2 min de lectura
El problema de una sola decisión
Un único comité decide antes de que se instale nada. Aprueba un plan: pruebas en QA, un documento de rollback, una fecha. Lo que no puede ver es cómo se comporta el cambio en un ambiente parecido a producción.
Dos puertas
El flujo de despliegue de DevGob tiene dos: Enviado a Comité autoriza la instalación en preproducción; Enviado a Comité Prod autoriza producción una vez que el cambio se instaló y validó en preproducción.
- La primera puerta revisa que el cambio esté listo: la revisión de código, los resultados de QA y el plan de rollback.
- La segunda puerta revisa la realidad: la evidencia de instalación en preproducción y la aceptación.
- Cada decisión queda registrada con su aprobador, su fecha y su número de acta.
¿Es más lento?
Agrega una decisión, que suele tomar minutos cuando la evidencia está completa. A cambio, los problemas encontrados en preproducción nunca llegan a los usuarios, y la aprobación de producción se apoya en hechos en lugar de expectativas.
Cuándo basta con una puerta
Los cambios estándar de bajo riesgo pueden no necesitar ambas. DevGob ya clasifica cada cambio como normal, estándar o de emergencia; los flujos dedicados para cambios estándar y de emergencia están en la hoja de ruta.
Sigue leyendo
DevOps con gobierno, en un solo registro
DevGob planifica el trabajo y gobierna cada cambio en su camino a producción: backlog, sprints, autorizaciones de comité, evidencia de instalación y auditoría.