¿Cómo administra las bases de datos en desarrollo, prueba y producción?

Question

He tenido dificultades para encontrar buenos ejemplos de cómo gestionar los esquemas de bases de datos y los datos entre los servidores de desarrollo, prueba y producción.

Aquí está nuestra configuración. Cada desarrollador tiene una máquina virtual que ejecuta nuestra aplicación y la base de datos MySQL. Es su caja de arena personal para hacer lo que quieran. Actualmente, los desarrolladores harán un cambio en el esquema de SQL y realizarán un volcado de la base de datos a un archivo de texto que se comprometerá en SVN.

Queremos implementar un servidor de desarrollo de integración continua que siempre ejecutará el último código comprometido. Si lo hacemos ahora, volverá a cargar la base de datos desde SVN para cada compilación.

Tenemos un servidor de prueba (virtual) que ejecuta "candidatos de lanzamiento". Implementar en el servidor de prueba es actualmente un proceso muy manual, y generalmente implica que cargue el SQL más reciente de SVN y lo ajuste. Además, los datos en el servidor de prueba son inconsistentes. Terminas con los datos de prueba que el último desarrollador haya tenido en su servidor de espacio aislado.

Donde todo se descompone es el despliegue a la producción. Como no podemos sobrescribir los datos en vivo con los datos de prueba, esto implica volver a crear manualmente todos los cambios de esquema. Si hubo una gran cantidad de cambios de esquema o scripts de conversión para manipular los datos, esto puede ponerse realmente complicado.

Si el problema era solo el esquema, sería un problema más fácil, pero también hay datos "base" en la base de datos que se actualizan durante el desarrollo, como los metadatos en las tablas de seguridad y permisos.

Esta es la mayor barrera que veo al avanzar hacia la integración continua y las compilaciones en un solo paso. ¿Cómo usted lo solucionó?

---

Un seguimiento pregunta: ¿cómo realizar un seguimiento de las versiones de bases de datos para que sepa qué secuencias de comandos a ejecutar para actualizar una instancia de base de datos dada? ¿Hay una tabla de versiones como Lance mencionada debajo del procedimiento estándar?

---

Gracias por la referencia a Tarantino. No estoy en un entorno .NET, pero encontré que su DataBaseChangeMangement wiki page fue muy útil. Especialmente este Powerpoint Presentation (.ppt)

Voy a escribir un script en Python que comprueba los nombres de *.sql scripts en un directorio dado en una tabla en la base de datos y ejecuta los que no están presentes en el orden basado en un número entero de que las formas la primera parte del nombre de archivo. Si es una solución bastante simple, como sospecho que será, la publicaré aquí.

---

Tengo un script de trabajo para esto. Maneja la inicialización del DB si no existe y la ejecución de scripts de actualización según sea necesario. También hay interruptores para borrar una base de datos existente e importar datos de prueba de un archivo. Se trata de 200 líneas, por lo que no lo publicaré (aunque podría ponerlo en pastebin si hay interés).

Answer 1

Hay un par de buenas opciones. No utilizaría la estrategia "restaurar una copia de seguridad".

1. Escriba todos los cambios de esquema y haga que su servidor CI ejecute esos scripts en la base de datos.Disponga de una tabla de versiones para realizar un seguimiento de la versión actual de la base de datos y solo ejecute las secuencias de comandos si son para una versión más nueva.

2. Utilice una solución de migración. Estas soluciones varían según el idioma, pero para .NET utilizo Migrator.NET. Esto le permite versionar su base de datos y moverse hacia arriba y hacia abajo entre versiones. Su esquema está especificado en el código C#.

Answer 2

Sus desarrolladores necesitan para escribir secuencias de comandos de cambio (esquema y de cambio de datos) para cada bug/función que trabajar, no simplemente volcar toda la base de datos de control de código fuente. Estos scripts actualizarán la base de datos de producción actual a la nueva versión en desarrollo.

Su proceso de compilación puede restaurar una copia de la base de datos de producción en un entorno apropiado y ejecutar todos los scripts desde el control de origen, que actualizará la base de datos a la versión actual. Hacemos esto diariamente para asegurarnos de que todos los scripts se ejecuten correctamente.

Answer 3

Si se encuentra en el entorno .NET, la solución es Tarantino. Maneja todo esto (incluso qué scripts sql instalar) en una compilación NANT.

Answer 4

Eche un vistazo a cómo lo hace Ruby on Rails.

Primero se denominan archivos de migración, que básicamente transforman el esquema de la base de datos y los datos de la versión N a la versión N + 1 (o en caso de degradación de la versión N + 1 a N). La base de datos tiene una tabla que le dice a la versión actual.

Las bases de datos de prueba siempre se borran antes de las pruebas unitarias y se rellenan con datos fijos de los archivos.

Answer 5

Esto es algo con lo que estoy constantemente insatisfecho, nuestra solución a este problema es que sí. Durante varios años mantuvimos un script de cambio por separado para cada lanzamiento. Este script contendría los deltas del último lanzamiento de producción. Con cada nueva versión de la aplicación, el número de versión incrementaría, dando algo como lo siguiente:

• dbChanges_1.sql
• dbChanges_2.sql
• ...
• dbChanges_n.sql

Esto funcionó bastante bien hasta que comenzamos a mantener dos líneas de desarrollo: Troncal/Mainline para nuevo desarrollo, y una rama de mantenimiento para correcciones de errores, mejoras a corto plazo, etc. Inevitablemente, surgió la necesidad de hacer que chan ges al esquema en la rama. En este punto, ya teníamos dbChanges_n + 1.SQL en el tronco, así que terminamos yendo con un esquema como el siguiente:

• dbChanges_n.1.sql
• dbChanges_n.2.sql
• ...
• dbChanges_n.3.sql

Una vez más, esto funcionó bastante bien, hasta que un día nos hacia arriba y vi 42 guiones delta en la línea principal y 10 en la rama. ARGH!

En estos días simplemente mantenemos un script delta y dejamos que SVN lo actualice, es decir, sobrescribimos el script con cada versión. Y evitamos hacer cambios de esquema en las sucursales.

Por lo tanto, tampoco estoy satisfecho con esto. Realmente me gusta el concepto de migraciones de Rails. Me he quedado bastante fascinado con LiquiBase. Es compatible con el concepto de refactorizaciones de bases de datos incrementales. Vale la pena echarle un vistazo y pronto lo veré en detalle. Alguien tiene experiencia con eso? Estaría muy interesado en conocer tus resultados.

Answer 6

Eche un vistazo a dbdeploy, hay herramientas de Java y .NET ya disponibles, puede seguir sus estándares para los diseños de archivos SQL y la tabla de versiones de esquema y escribir su versión de python.

Answer 7

Tenemos una configuración muy similar a la OP.

Los desarrolladores desarrollan en máquinas virtuales con bases de datos privadas.

[Desarrolladores pronto estará cometiendo en ramas particulares]

Las pruebas se ejecutan en máquinas diferentes (en realidad en en VM alojada en un servidor) [pronto estará a cargo de servidor de Hudson CI]

prueba cargando el volcado de referencia en el db. Aplique los parches de esquema de desarrolladores luego aplique los parches de datos de desarrolladores

Luego ejecute las pruebas de unidad y sistema.

La producción se implementa en clientes como instaladores.

lo que hacemos:

echamos un volcado esquema de nuestra caja de arena DB. Luego, un volcado de datos sql. Diferimos eso a la línea base anterior. ese par de deltas es para actualizar n-1 a n.

configuramos los volcados y deltas.

Así que para instalar la versión N CLEAN ejecutamos el volcado en un db vacío. Para aplicar parches, aplique los parches intermedios.

(Juha mencionado la idea de carril de tener una mesa de grabación de la versión actual DB es buena y debe hacer la instalación de actualizaciones menos cargada.)

Deltas y vertederos tienen que ser revisado antes de la prueba beta. No veo ninguna forma de evitar esto, ya que he visto a los desarrolladores insertar cuentas de prueba en la base de datos por sí mismos.

Answer 8

Me temo que estoy de acuerdo con otros carteles. Los desarrolladores necesitan guiar sus cambios.

En muchos casos, una simple ALTER TABLE no funcionará, también debe modificar los datos existentes: los desarrolladores necesitan tener en cuenta qué migraciones se requieren y asegurarse de que estén escritas correctamente (por supuesto, debe probar esto cuidadosamente en algún punto del ciclo de lanzamiento).

Además, si tiene algún sentido, conseguirá que los desarrolladores realicen retrocesos de scripts para sus cambios, así se pueden revertir si es necesario. Esto también debe probarse, para garantizar que su reversión no solo se ejecute sin error, sino que deje el DB en el mismo estado que antes (esto no siempre es posible o deseable, pero es una buena regla la mayor parte del tiempo) .

Cómo se engancha eso en un servidor de CI, no lo sé.Tal vez su servidor de CI necesite tener una instantánea de compilación conocida, a la que revierte todas las noches y luego aplique todos los cambios desde entonces. Probablemente sea mejor, de lo contrario, una secuencia de comandos de migración interrumpida no solo romperá la compilación de esa noche, sino todas las subsiguientes.

Answer 9

También puede buscar en el uso de una herramienta como SQL Compare a la escritura de la diferencia entre distintas versiones de una base de datos, lo que le permite migrar rápidamente entre las versiones

Answer 10

He escrito una herramienta que (enganchando en Open DBDiff) compara esquemas de base de datos, y sugerirá scripts de migración para usted. Si realiza un cambio que elimina o modifica los datos, arrojará un error, pero proporcionará una sugerencia para el script (por ejemplo, cuando falte una columna en el nuevo esquema, se verificará si la columna ha sido renombrada y se creará xx - generado script.sql.suggestion que contiene una instrucción de cambio de nombre).

http://code.google.com/p/migrationscriptgenerator/ SQL Server sólo me temo :(También es bastante alfa, pero es muy baja fricción (sobre todo si se combina con Tarantino o http://code.google.com/p/simplescriptrunner/)

La forma en que uso que es tener un SQL las secuencias de comandos proyectan en su .sln. También tiene una base de datos db_next localmente a la que realiza los cambios (usando Management Studio o NHibernate Schema Export o LinqToSql CreateDatabase o algo así). Luego ejecuta migrationscriptgenerator con _dev y _next DBs, lo que crea. las secuencias de comandos de actualización SQL para migrar al otro lado.

Answer 11

El libro Refactoring Databases: Evolutionary Database Design puede brindarle algunas ideas sobre cómo administrar th e base de datos. También se puede leer una versión corta en http://martinfowler.com/articles/evodb.html

En un proyecto PHP + MySQL he almacenado el número de revisión de la base de datos y cuando el programa se conecta a la base de datos, primero verifica la revisión. Si el programa requiere una revisión diferente, se abrirá una página para actualizar la base de datos. Cada actualización se especifica en código PHP, que cambiará el esquema de la base de datos y migrará todos los datos existentes.

Answer 12

• Nombre bases de datos de la siguiente manera - db_dev, db_test, db_qa, db_prod (obviamente nunca se debe codificar nombres db
• Así que sería capaz de desplegar incluso los diferentes tipos de los DB en el mismo servidor físico (que hago no lo recomiendo, pero puede que tenga que ... si los recursos son escasos)
• Asegúrese de poder mover los datos entre esos automáticamente
• Separe los scripts de creación db de la población = Siempre debería ser posible recrear el db desde cero y rellenelo (desde la versión anterior de db o la fuente de datos externa
• No use cadenas de conexión de código duro en el código (incluso en los archivos de configuración): use en las plantillas de cadena de conexión de archivos de configuración, que rellena dinámicamente, cada reconfiguración de la aplicación que necesita recompilar es MALO
• hacer utilizar versiones de base de datos y objetos de base de datos de versiones - si se lo puede permitir utilizar productos listos, si no desarrollar algo en su propia pista
• cada cambio de DDL y guardarlo en alguna tabla de historial (example here)
• copias de seguridad diarias!Pruebe qué tan rápido podrá restaurar algo perdido de una copia de seguridad (use los scripts de restauración automáticos
• incluso su base de datos DEV y el PROD tienen exactamente el mismo script de creación, tendrá problemas con los datos, así que permita a los desarrolladores crear los mismos Copie de prod y juegue con él (sé que recibiré menos para este, pero cambie la mentalidad y el proceso de negocio le costará mucho menos cuando la mierda golpee al ventilador, así que obligue a los codificadores a subinvertir legalmente lo que sea que haga, pero garantizar éste

Answer 13

Estamos utilizando la línea de comandos mysql-diff:. emite una diferencia entre dos esquemas de bases de datos (de DB en vivo o script) como ALTER secuencia de comandos mysql-diff se ejecuta al inicio de la aplicación, y si el esquema cambió, informa s al desarrollador. Entonces los desarrolladores no necesitan escribir ALTERs manualmente, las actualizaciones de esquema ocurren de forma semiautomática.

Answer 14

Para la base de datos de Oracle utilizamos oracle-ddl2svn herramientas.

Esta herramienta automatizada próximo proceso

1. para cada esquema de esquema para hacerse db DDLs
2. se pone debajo de la versión contol

cambios entre los casos resueltos manualmente