Sí. Debería poder reconstruir cualquier parte de su sistema desde el control de la fuente, incluida la base de datos (y también argumentaría ciertos datos estáticos).

Suponiendo que no quieres tener una herramienta para hacerlo, te sugiero que quieras incluir lo siguiente:

• Scripts de creación para las estructuras de tablas básicas, incluidos esquemas, usuarios, tablas, claves, valores predeterminados, etc.
• Actualice los scripts (ya sea modificando la estructura de la tabla o migrando datos de un esquema anterior al nuevo)
• Scripts de creación para procedimientos almacenados, índices, vistas, activadores (no necesita preocuparse por la actualización de estos, ya que solo sobrescribe lo que había con el script de creación correcto)
• Scripts de creación de datos para que el sistema se ejecute (un solo usuario, cualquier dato de lista de selección estática, ese tipo de cosas)

Todos los scripts deben incluir las declaraciones de eliminación apropiadas y deben escribirse para que puedan ejecutarse como cualquier usuario (por lo tanto, incluir los prefijos de esquema / propietario asociados, si es relevante).

El proceso para actualizar / etiquetar / ramificar debe ser exactamente como el resto del código fuente. No tiene mucho sentido hacerlo si no puede asociar una versión de la base de datos con una versión de la aplicación.

Por cierto, cuando dices que la gente solo puede actualizar el servidor de prueba, espero que te refieras al servidor de desarrollo. Si los desarrolladores están actualizando el servidor de prueba sobre la marcha, entonces estás viendo un mundo de dificultades cuando se trata de resolver lo que necesitas liberar.

Sí.

  

¿Cuál es el mejor método para conservarlo y actualizarlo allí?

Um. Escribe un script de constructor de esquemas. Compruébalo después de hacer cambios. Compruébalo antes de ejecutarlo.

Es difícil determinar lo que estás pidiendo.

Escribir scripts de migración de esquemas formales. Registrarlos después de la prueba. Échales un vistazo antes de ejecutarlos.

¿Qué más hay?

Lo que sucede es que los cambios de esquema se convierten en problemas complicados porque el esquema evoluciona orgánicamente a través de una serie de cambios no documentados.

Esta evolución orgánica hace que la migración de esquemas sea más difícil porque no hay una fuente "autorizada" para lo que se supone que está allí. Hay dos versiones de producción ligeramente diferentes, una versión de prueba, una versión de control de calidad y ocho versiones de desarrollo. Todas ligeramente diferentes.

Si hubo una única fuente autorizada, entonces la migración de esquema es solo el delta entre la última versión y esta versión.

Sí

Los scripts de base de datos (ddl, dml) son códigos. Todo el código debe estar en un sistema de control de versiones.

Migraciones

• Usar migraciones de base de datos

Le permite utilizar los mismos archivos de base de datos en desarrollo, qa y versiones.

• Lanzamiento a la base de datos con un número de lanzamiento

Almacene el número de versión en algún lugar para la auditoría, muchos lo almacenan en la propia db. Cada versión se compondrá de migraciones que llevarán la base de datos a la versión correcta.

Existen herramientas como liquibase que están destinadas a proporcionar control de origen para las bases de datos. Es incómodo mantener los scripts de cambio / actualización en su herramienta de control de código fuente normal como muchas empresas lo hacen y no siempre puede volver a implementar la base de datos desde cero.

También intentamos automatizar esto con las herramientas de comparación de bases de datos (comparar datos maestros y clientes) y eso ayudó, pero no puedes confiar en esas herramientas al 100%, definitivamente también necesitas un proceso de revisión.

Sí

Y además, querrás sucursales .

Uso Git para sucursales:

• para el desarrollo por función (como hacemos para el desarrollo regular del resto de la aplicación)

• y uno para el servidor de producción también porque los clientes que usan la aplicación también crean contenidos.

De esa manera, obtendrá los beneficios del control de origen y la bifurcación tanto para los códigos de origen como para la base de datos (y cualquier otro archivo que tenga).

Todavía no he encontrado un sistema todo en uno [para PostgreSQL], por lo que tuve que escribir funciones / scripts para reindexar correctamente al fusionar las sucursales (por ejemplo, no se debe modificar ningún índice de la rama de producción porque los clientes confían en en ellos, mientras que los índices + las claves externas de la rama de desarrollo que se intersectan con los contenidos de producción deben reindexarse: no funcionaría para todas las aplicaciones, pero cubre todos los casos de nuestra aplicación, por lo que es lo suficientemente bueno).

Pero la idea general es que el contenido de la base de datos es una parte esencial de la aplicación, y todos los recursos deben estar en control de fuente , ergo sí, también debe usar el control de fuente para la base de datos.

Para Java, nuestro equipo utiliza Flyway , que consideramos realmente fácil de usar y potente.

Si estás trabajando en Ruby, Rails tiene Migrations que también son una forma poderosa de resolver este problema.

Liquibase ya se ha mencionado, es una buena solución, pero me pareció más complicada que otras alternativas como Flyway.

Además, el software RedGate ofrece un producto llamado Control de fuente SQL que Está diseñado para SQL Server. No lo he usado, pero uno de mis compañeros de trabajo dice que es genial.

Este es el problema que he visto muchas veces cuando no hay control de versiones o administración de cambios en las bases de datos de desarrollo. El programador A realiza un cambio en una tabla, vista o proceso. El programador B realiza un cambio en lo mismo y sobrescribe lo que hizo el programador A. O bien, DBA restaura un DB de producción al desarrollo y sobrescribe los cambios. He visto que este tipo de cosas causan una pena considerable tantas veces que no es gracioso. Y esto es solo en sistemas de desarrollo. Las cosas pueden ensuciarse mucho cuando la puesta en escena / prueba e incluso los servidores de producción quedan atrapados en esto.

El control de versión de la base de datos no tiene que ser el mismo que el control de versión de código normal para que sea efectivo. Sin embargo, algún tipo de control de cambios y copias de seguridad del historial evitarán muchos problemas.

Piense en ello como "Control de versión" en lugar de "Control de fuente". Esto implica que puede ver el historial completo de ese script en particular. Si puede o no reconstruir la base de datos a su forma actual, será más una cuestión de sus prácticas con respecto a estos scripts y cualquier marco utilizado para crearlos.

Para nuestros proyectos PHP / MySQL, hemos estado utilizando una (una) pequeña herramienta llamada Ladder . Está diseñado para facilitar el crecimiento orgánico de una base de datos a lo largo del tiempo. Todas las migraciones de un proyecto se almacenan en el control de revisión / fuente / versión, y se rastrean junto con el código.

Admite agregar / alterar / eliminar columnas, ejecutar consultas, agregar / eliminar índices, restricciones, etc. Seguirá el estado de la base de datos y aplicará las migraciones que faltan. También le permite "retroceder en el tiempo" especificando la migración en la que debe estar. ( php ladder.php migrate 15 )

Ah, y la última adición es la diferencia de base de datos. Ejecute el comando diff-save , agregue y elimine algunas columnas de la base de datos y ejecute el comando diff . Verá un código de migración generado automáticamente en función del estado de la base de datos.

DataGrove resuelve algunos de los problemas mencionados aquí (por jfrankcarr , por ejemplo)

Realiza un seguimiento de todos los cambios en una base de datos y le permite guardar una versión de todo el estado de la base de datos en un repositorio. Luego le permite generar múltiples copias virtuales de la misma base de datos, por lo que cada desarrollador o DBA puede tener su propia copia por separado (cada copia virtual puede generarse a partir de una versión diferente). Se asegurará de que nadie anule el código / cambios de otra persona. Cada una de las copias virtuales también se rastrea en los mismos repositorios para que todos los estados de la base de datos se puedan compartir y recrear fácilmente.

También me gustaría traer una herramienta de monitoreo que también pueda usarse como herramienta de control de versiones de datos. La herramienta de la que estoy hablando es MONyog, en realidad es una herramienta de monitoreo de MySQL, pero con un pequeño truco podemos usarla fácilmente como versión de datos.

Pero antes de seguir adelante, citaré que no será aconsejable colocar toda la base de datos para el control de versiones. Es un verdadero asesino rastrear el cambio para un conjunto particular de datos.

MONyog tiene una función llamada CSO (Objetos SQL personalizados), que puede monitorear el cambio en un conjunto particular de datos. Aquí se describe cómo agregar un CSO aquí . Ahora, en la sección de historial de monitores de MONyog, puede obtener los cambios durante un período de tiempo. Mejor, da un informe visual en la página html. El informe se verá algo así.