Martin Fowler escribió mi artículo favorito sobre el tema, http://martinfowler.com/articles/evodb.html. Elijo no poner volcados de esquema bajo el control de versiones como alumb y otros sugieren porque quiero una manera fácil de actualizar mi base de datos de producción.
Para una aplicación web donde tendré una única instancia de base de datos de producción, utilizo dos técnicas:
Secuencias de comandos de actualización de base de datos
Una secuencia de comandos de actualización de la base de datos que contiene el DDL necesario para mover el esquema de la versión N a la N+1. (Estos van en su sistema de control de versiones). Una tabla _version_history_, algo así como
create table VersionHistory (
Version int primary key,
UpgradeStart datetime not null,
UpgradeEnd datetime
);
obtiene una nueva entrada cada vez que se ejecuta un script de actualización que corresponde a la nueva versión.
Esto garantiza que sea fácil ver qué versión del esquema de la base de datos existe y que los scripts de actualización de la base de datos se ejecuten solo una vez. Nuevamente, estos no son volcados de bases de datos. Más bien, cada secuencia de comandos representa los cambios necesario para pasar de una versión a la siguiente. Son el script que aplica a su base de datos de producción para "actualizarla".
Sincronización de la zona de pruebas del desarrollador
- Un script para respaldar, desinfectar y reducir una base de datos de producción. Ejecute esto después de cada actualización a la base de datos de producción.
- Una secuencia de comandos para restaurar (y modificar, si es necesario) la copia de seguridad en la estación de trabajo de un desarrollador. Cada desarrollador ejecuta este script después de cada actualización a la base de datos de producción.
Advertencia:mis pruebas automatizadas se ejecutan en una base de datos vacía pero con un esquema correcto, por lo que este consejo no se adaptará perfectamente a sus necesidades.
