No hay ni un solo programador que no se haya visto en una situación como esta. Se acaba de realizar un despliegue a producción y aparece un error que hasta ese momento no había sido detectado. Rápidamente pides acceso a producción porque sabes perfectamente cual es el problema y quieres solucionarlo.

Esta claro que hay un problema, pero no es otro que un programador que piensa que debe tener acceso a los servidores de producción para poder solucionar un problema online.

Para un buen proyecto como mínimo debe haber cuatro entornos.

• El entorno de desarrollo y pruebas local de cada programador.
• Un entorno donde se realizan pruebas de integracion tanto manuales como integradas.
• Un entorno de preproducción donde el equipo de QA y los usuarios realizan las pruebas de aceptación
• Un entorno de producción.

Aunque sea el crack más grande del planeta un programador jamas debe tener acceso más alla de su entorno de desarrollo. Cuando el código es subido al sistema de control de versiones y desplegado, el programador debe ser un mero espectador. Lo mismo sucede con el equipo QA o los usuarios. El entorno en el cual deben trabajar es el de preproducción y no tienen porque tener ni porque “mirar” en el entorno de pruebas o de desarrollo. Si hay una versión nueva disponible, el responsable de versiones deberá moverlas al siguiente entorno para que el ciclo de vida del proyecto siga avanzando.

Si hay un error en producción, debe ser solucionado por el equipo de operaciones. Si no pueden arreglarlo, el desarrollador deberá correguir el bug en su entorno, subirlo a gestor de versiones y desde alli esperar la validación del equipo de QA. Cuando este todo correcto se podrá realizará un parche que se subirá a producción.

No seas responsable de una catastrofe en tus servicios por tocar en producción directamente.

Adaptado de un consejo de Cal Evans.