Sí, necesita un entorno de prueba o de ensayo en el que siga todos los pasos, pero es obligatorio mantener archivos de configuración separados para entornos separados.
Environments
|_property_files
|_ dev
|_ com.bla.util
| |_ example.properties
|_ com.bla.beans
| |_ someconfig.xml
|_ test
....
|_ production
....
|_database_updates
|_ dev
|_ insert_new_static_data.sql
|_ ...
...
Básicamente, en mis scripts de compilación e implementación, tomo una propiedad de entorno que buscará los archivos de metadatos específicos del entorno, como los archivos XML, y los reemplazará en mi ubicación de compilación antes de empaquetarlos. Además, en mis scripts de implementación, buscaré cualquier archivo SQL en las actualizaciones de la base de datos y también los ejecutaré en la base de datos configurada para ese entorno.
Podría hacer esto con una tarea de compilación personalizada, pero en realidad solo uso algunas pruebas JUnit para hacer esto por mí. Si se produce alguna excepción de SQL, la prueba falla y, por lo tanto, la implementación falla. En términos generales, también los scripts SQL tienen inteligencia, si los datos necesarios ya existen en el entorno, se saltan la inserción o la actualización.
También tengo un directorio similar para scripts de lotes o shell que necesito ejecutar para un entorno específico.
Lo que dice todo en su pregunta es esto: siempre deben actualizarse, pero no lo harán.
Estas configuraciones impulsan sus compilaciones e implementaciones automatizadas, por lo que si NO las actualiza, sus compilaciones fallarán y su gerente recibirá un correo electrónico al respecto. Es tan importante para el equipo mantener las configuraciones de compilación y despliegue para una versión específica como lo es para ellos verificar el código que compila. Cualquiera de las infracciones rompe la construcción.
En resumen, una mayor adopción de los principios de integración continua (CI) ayudará a eliminar el dolor de los lanzamientos de producción.