Esto no es un error
Al menos no en tu código. Es un error en su proceso . Su administrador de proyectos debería estar mucho más preocupado por su proceso que por su código.
¿Cómo lidias con esto?
Sencillamente, al no permitir que los ingenieros cambien las bases de datos de producción o de desarrollo compartido .
Suponiendo que esta es una base de datos de desarrollo compartida:
Idealmente, si es posible, evita tener una base de datos compartida en primer lugar . En su lugar, tener bases de datos por desarrollador que son de corta duración. Esto debería automatizarse con scripts, de lo contrario, el costo de la prueba se vuelve demasiado grande y hay un incentivo para no probar las cosas. Puede tener estas bases de datos en la estación de trabajo del desarrollador o en un servidor central.
Si, por alguna razón, DEBES tener una base de datos compartida, debes usar fixtures - esencialmente, algo que establece la base de datos en un estado de bien conocido cada vez que necesita usarla. Esto evita que los desarrolladores sean mordidos por los cambios de otras personas.
Si necesita aplicar cambios permanentes a la base de datos, debe confirmarlos a su control de fuente . Configure su base de datos de modo que los desarrolladores no tengan permiso para escribir en ella directamente, y tengan un programa que extraiga los cambios del control de origen y los aplique.
Finalmente, según su descripción de cómo está depurando las cosas, parece que no está utilizando CI . Utiliza CI . Es un poco difícil de configurar, pero ahorrará mucho tiempo a largo plazo, por no mencionar que evitará que se preocupe por errores de base de datos que no se pueden reproducir. Solo tendrás que preocuparte por los heisenbugs ahora!
Suponiendo que esta es una base de datos de producción:
Si sus desarrolladores están cambiando las bases de datos de producción, muchas cosas han salido terriblemente mal, incluso si los cambios son absolutamente correctos.
Los desarrolladores nunca deben acceder a las bases de datos de producción . No hay absolutamente ninguna razón para hacerlo, y hay tantas cosas que pueden salir muy mal muy .
Si necesita arreglar algo en una base de datos de producción, primero realice una copia de seguridad, restaure esa copia de seguridad en una instancia de diferente (desarrollo) y luego jugar alrededor de esa base de datos de desarrollo. Una vez que cree que tiene una solución lista (en el control de código fuente), vuelve a realizar la restauración, aplica la solución y ve el resultado.
Luego, después de hacer una copia de seguridad de las cosas nuevamente (e idealmente evitar las actualizaciones concurrentes), arregla la instancia de producción, idealmente a través de un parche de software.
Si necesita probar algo en una base de datos de producción ... no, no lo hace. Independientemente de las pruebas que necesite realizar, debe realizarlas en una instancia de desarrollo. Si necesita algunos datos para realizar las pruebas, puede obtener esos datos allí.