Mejores prácticas de implementación de bases de datos

Question

Principalmente cambiamos tablas de bases de datos existentes, procedimientos almacenados, funciones o parámetros en tablas para actualizaciones de software/correcciones de errores. Y cuando llega el momento de implementar nuestros cambios en otro entorno, como la producción o la preproducción, algunas partes de nuestros cambios de db se olvidan.

En nuestra empresa, algunos desarrolladores utilizan una aplicación de análisis de diferencia de base de datos para conocer las diferencias entre el entorno de prueba y producción. Algunos desarrolladores almacenan t-sql de cada cambio que hicieron en db, como yo.

Me pregunto qué estás haciendo para implementar cambios de db en el entorno de producción. ¿Por qué eliges de esa manera? O lo que debe hacerse?

Gracias por las respuestas!

Answer 1

Tenemos nuestro db en Source Control. Cualquier cambio se rastrea de esa manera. Cualquier otra cosa sería una pesadilla.

Jeff tiene un artículo sobre ella también - http://blog.codinghorror.com/get-your-database-under-version-control/

Dependiendo de la configuración y la base de datos, el Asistente de publicación de bases de datos - http://www.codeplex.com/sqlhost/Wiki/View.aspx?title=Database%20Publishing%20Wizard - puede ser realmente útil.

Answer 2

La creación de secuencias de comandos y el almacenamiento de cada cambio realizado en SQL es la mejor forma de OMI.

Answer 3

En un proyecto, tengo todos mis cambios DB en scripts DDL. Esos scripts contienen las instrucciones SQL que son necesarias para actualizar el DB a una cierta versión. El nombre de archivo del script también contiene el número de versión del DB al que se actualizará el DB (_versionnumber.sql)

Además de eso, tengo una pequeña aplicación que actualiza el DB a la última versión, ejecutando esos archivos de script en el orden correcto (desde la versión actual del DB al último script-file).

Para proyectos nuevos, ahora uso Migrator.NET. Este marco le permite escribir sus cambios de DB en clases de C#. El marco tiene una aplicación de consola con la que puede ejecutar los cambios de DB, y también es posible usarlo con msbuild.

Answer 4

Cada objeto de base de datos debe almacenarse en un archivo separado en el sistema de control de versiones. sistema de control de versiones podría contener archivos como en este ejemplo:

|- tables 
    |- employees.sql 
    |- contracts.sql 
|- packages 
    |- contract_api.sql 
|- functions 
    |- get_employee_name.sql 
...etc... 

Siempre que modifique algún objeto DB, entonces también debe modificar el archivo de SQL adecuado (DDL) en el sistema de control de versiones. Por ejemplo, si modifica el paquete contract_api, actualiza el archivo contract_api.sql. Como este archivo ha sido modificado, puede ser instalado, por ejemplo, mediante un motor de integración continua.

PERO, como usted sabe, hay scripts DDL, que no se pueden ejecutar dos veces. Por ejemplo, la secuencia de comandos 'CREATE TABLE mytable ...' se puede ejecutar solo una vez. Y si su sistema ya está en producción, entonces no puede permitirse la declaración 'DROP TABLE mytable' en el encabezado de su script 'CREATE TABLE ...'. Por lo tanto, para los sistemas de producción necesita crear los llamados delta delta que solo entregarán cambios. En este caso, simplemente podría crear un nuevo archivo llamado employees_upd01.sql que contenga la declaración 'ALTER TABLE mytable ADD COLUMN ...'.

Después de algún tiempo su repositorio podría tener este aspecto:

|- tables 
    |- employees.sql 
    |- employees_upgr20091001.sql 
    |- employees_upgr20091004.sql 
    |- contracts.sql 
|- packages 
    |- contract_api.sql 
|- functions 
    |- get_employee_name.sql 
...etc... 

Y esto está bien, porque: 1) cuando se necesita para entregar los cambios incrementales de hoy a la base de datos - implementar los archivos que fueron modificados hoy 2) si necesita implementar una instalación limpia de su sistema - ejecuta todos los scripts en orden, por ejemplo primera employees.sql, entonces employees_upgr20091001.sql, etc.

Como cada objeto de base de datos está en un archivo separado en el sistema de control de versiones, que tiene un buen control sobre todos los cambios.