tools source control database version-control

database - source - ¿Utiliza control de código fuente para los elementos de su base de datos?



sql source control (30)

Creo que cada base de datos debe estar bajo control de código fuente, y los desarrolladores deberían tener una forma fácil de crear su base de datos local desde cero. Inspirado por Visual Studio para profesionales de bases de datos, he creado una herramienta de código abierto que crea secuencias de comandos de bases de datos MS SQL, y proporciona una manera fácil de implementarlas en su motor de base de datos local. Pruebe http://dbsourcetools.codeplex.com/ . Diviértete, - Nathan.

Siento que mi tienda tiene un agujero porque no tenemos un proceso sólido implementado para versionar los cambios de esquema de nuestra base de datos. Hacemos muchas copias de seguridad, por lo que estamos más o menos cubiertos, pero es una mala práctica confiar en su última línea de defensa de esta manera.

Sorprendentemente, esto parece ser un hilo común. Muchas de las tiendas con las que he hablado ignoran este problema porque sus bases de datos no cambian a menudo y, básicamente, intentan ser meticulosas.

Sin embargo, sé cómo va esa historia. Es solo cuestión de tiempo antes de que las cosas se alineen mal y algo se pierda.

¿Existen buenas prácticas para esto? ¿Cuáles son algunas estrategias que han funcionado para usted?

Debe leer Obtenga su base de datos bajo control de versiones . Revisa la serie de publicaciones de K. Scott Allen.

Cuando se trata del control de versiones, la base de datos suele ser un segundo o incluso un ciudadano de tercera clase. Por lo que he visto, los equipos que nunca pensarían en escribir código sin control de versiones en un millón de años, y con razón, de alguna manera pueden ser completamente ajenos a la necesidad del control de versiones en las bases de datos críticas en las que se basan sus aplicaciones. No sé cómo puede llamarse a sí mismo un ingeniero de software y mantener una cara seria cuando su base de datos no está exactamente bajo el mismo nivel riguroso de control de fuente que el resto de su código. No dejes que esto te pase a ti. Obtenga su base de datos bajo control de versiones.

Echa un vistazo a LiquiBase para administrar los cambios en la base de datos usando el control de código fuente.

El esquema más exitoso que he usado en un proyecto ha combinado copias de seguridad y archivos diferenciales de SQL. Básicamente, tomaríamos una copia de seguridad de nuestra base de datos después de cada lanzamiento y haríamos un volcado de SQL para que pudiéramos crear un esquema en blanco desde cero si fuera necesario. Luego, en cualquier momento en que necesitara realizar un cambio en la base de datos, agregaría un script de modificación al directorio SQL bajo el control de versiones. Siempre prefijamos un número de secuencia o una fecha al nombre del archivo, por lo que el primer cambio sería algo así como 01_add_created_on_column.sql, y la siguiente secuencia de comandos sería 02_added_customers_index. Nuestra máquina de CI los buscaría y los ejecutaría secuencialmente en una copia nueva de la base de datos que se había restaurado desde la copia de seguridad.

También tuvimos algunos scripts en el lugar que los desarrolladores podrían usar para reinicializar su base de datos local a la versión actual con un solo comando.

En nuestro negocio usamos scripts de cambio de base de datos. Cuando se ejecuta un script, su nombre se almacena en la base de datos y no se ejecutará de nuevo, a menos que se elimine esa fila. Los scripts se nombran según la fecha, la hora y la rama del código, por lo que es posible la ejecución controlada.

Muchas y muchas pruebas se realizan antes de que los scripts se ejecuten en el entorno real, por lo que "oopsies" solo ocurren, en general, en bases de datos de desarrollo.

Estamos en el proceso de mover todas las bases de datos al control de origen. Estamos utilizando sqlcompare para crear un script de la base de datos (una característica de edición de profesión, desafortunadamente) y poner ese resultado en SVN.

El éxito de su implementación dependerá mucho de la cultura y las prácticas de su organización. La gente aquí cree en la creación de una base de datos por aplicación. Existe un conjunto común de bases de datos que son utilizadas por la mayoría de las aplicaciones y causan una gran cantidad de dependencias interdatabase (algunas de ellas son circulares). Poner los esquemas de la base de datos en el control de origen ha sido notoriamente difícil debido a las dependencias interdatabase que tienen nuestros sistemas.

La mejor de las suertes para usted, cuanto antes lo pruebe, más pronto resolverá sus problemas.

Esto siempre ha sido una gran molestia para mí también. Parece que es demasiado fácil hacer un cambio rápido en su base de datos de desarrollo, guardarlo (olvidarse de guardar un script de cambio) y luego se queda atascado. Podría deshacer lo que acaba de hacer y rehacerlo para crear el script de cambio, o escribirlo desde cero si lo desea, por supuesto, aunque es mucho tiempo dedicado a escribir scripts.

Una herramienta que he usado en el pasado que me ha ayudado con esto es SQL Delta. Le mostrará las diferencias entre dos bases de datos (servidor SQL / Oracle, creo) y generará todos los scripts de cambio necesarios para migrar A-> B. Otra cosa buena que hace es mostrar todas las diferencias entre el contenido de la base de datos entre la base de datos de producción (o prueba) y su base de datos de desarrollo. Dado que cada vez más aplicaciones almacenan la configuración y el estado que es crucial para su ejecución en las tablas de la base de datos, puede ser un verdadero problema tener scripts de cambio que eliminen, agreguen y alteren las filas adecuadas. SQL Delta muestra las filas en la base de datos tal como se verían en una herramienta de diferencia: modificada, agregada, eliminada.

Una excelente herramienta. Aquí está el enlace: http://www.sqldelta.com/

Ha habido mucha discusión sobre el modelo de base de datos en sí, pero también mantenemos los datos necesarios en archivos .SQL.

Por ejemplo, para que sea útil, su aplicación podría necesitar esto en la instalación:

INSERT INTO Currency (CurrencyCode, CurrencyName) VALUES (''AUD'', ''Australian Dollars''); INSERT INTO Currency (CurrencyCode, CurrencyName) VALUES (''USD'', ''US Dollars'');

Tendríamos un archivo llamado currency.sql bajo subversión. Como paso manual en el proceso de compilación, comparamos el currency.sql anterior al más reciente y escribimos un script de actualización.

He utilizado la herramienta dbdeploy de ThoughtWorks en http://dbdeploy.com/ . Se fomenta el uso de scripts de migración. En cada versión, consolidamos los scripts de cambio en un solo archivo para facilitar la comprensión y permitir que los DBA "bendigan" los cambios.

La mejor práctica que he visto es crear un script de compilación para desechar y reconstruir su base de datos en un servidor de prueba. A cada iteración se le asignó una carpeta para los cambios en la base de datos, todos los cambios se crearon con el comando "Eliminar ... Crear". De esta manera, puede revertir a una versión anterior en cualquier momento, apuntando la compilación a la carpeta que desea versionar.

Creo que esto se hizo con NaNt / CruiseControl.

Las bases de datos en sí? No

Los scripts que los crean, incluyendo inserciones de datos estáticos, procedimientos almacenados y similares; por supuesto. Son archivos de texto, se incluyen en el proyecto y se registran dentro y fuera como todo lo demás.

Por supuesto, en un mundo ideal, su herramienta de administración de base de datos haría esto; Pero solo hay que ser disciplinado al respecto.

Lo hago guardando crear / actualizar scripts y un script que genera datos muestreados.

Los nuevos proyectos de base de datos en Visual Studio proporcionan control de fuente y guiones de cambio.

Tienen una buena herramienta que compara bases de datos y puede generar un script que convierte el esquema de uno en otro, o actualiza los datos en uno para que coincida con el otro.

El esquema de la base de datos se "destruye" para crear muchos, muchos archivos pequeños .sql, uno por comando DDL que describe la base de datos.

+ tom

Información adicional 2008-11-30

Lo he estado usando como desarrollador durante el último año y me gusta mucho. Facilita la comparación de mi trabajo de desarrollo con la producción y la generación de un script para usarlo para el lanzamiento. No sé si faltan las características que los DBA necesitan para proyectos "de tipo empresarial".

Debido a que el esquema se "destruye" en archivos sql, el control de origen funciona bien.

Una idea es que necesitas tener una mentalidad diferente cuando usas un proyecto db. La herramienta tiene un "proyecto de db" en VS, que es solo el sql, más una base de datos local generada automáticamente que tiene el esquema y algunos otros datos de administración, pero ninguno de los datos de su aplicación, más su db de desarrollo local que usa para aplicación de datos dev trabajo. Raramente se da cuenta de la base de datos generada automáticamente, pero debe saber que está allí para poder dejarlo solo :). Este db especial es claramente reconocible porque tiene un Guid en su nombre,

El Proyecto VS DB hace un buen trabajo al integrar los cambios de db que otros miembros del equipo han realizado en su proyecto local / db asociado. pero necesita dar un paso adicional para comparar el esquema del proyecto con su esquema local de desarrollo de datos y aplicar los mods. Tiene sentido, pero parece incómodo al principio.

Los proyectos DB son una herramienta muy poderosa. No solo generan scripts sino que pueden aplicarlos inmediatamente. Asegúrese de no destruir su db de producción con él. ;)

Realmente me gustan los proyectos VS DB y espero usar esta herramienta para todos mis proyectos db en el futuro.

+ tom

Me encantan las migraciones de Rails ActiveRecord. Extrae el script de DML a ruby, que luego puede ser fácilmente versionado en su repositorio de origen.

Sin embargo, con un poco de trabajo, podrías hacer lo mismo. Cualquier cambio de DDL (ALTER TABLE, etc.) se puede almacenar en archivos de texto. Mantenga un sistema de numeración (o un sello de fecha) para los nombres de archivo y aplíquelos en secuencia.

Rails también tiene una tabla de ''versión'' en la base de datos que realiza un seguimiento de la última migración aplicada. Puedes hacer lo mismo fácilmente.

Normalmente construyo un script SQL para cada cambio que hago, y otro para revertir esos cambios, y mantengo esos scripts bajo el control de versiones.

Luego tenemos un medio para crear una nueva base de datos actualizada a pedido, y podemos movernos fácilmente entre revisiones. Cada vez que hacemos una versión, agrupamos los scripts (requiere un poco de trabajo manual, pero en realidad rara vez es difícil ), por lo que también tenemos un conjunto de scripts que se pueden convertir entre versiones.

Sí, antes de que lo digas, esto es muy similar a lo que hacen Rails y otros, pero parece funcionar bastante bien, así que no tengo problemas en admitir que deseché la idea sin vergüenza :)

Nosotros controlamos la versión y la fuente de todo lo que rodea a nuestras bases de datos:

  • DDL (crear y altera)
  • DML (datos de referencia, códigos, etc.)
  • Cambios en el modelo de datos (usando ERwin o ER / Studio)
  • Cambios en la configuración de la base de datos (permisos, objetos de seguridad, cambios generales de configuración)

Hacemos todo esto con trabajos automatizados utilizando Change Manager y algunos scripts personalizados. Tenemos un administrador de cambios que monitorea estos cambios y notifica cuando se realizan.

Nosotros controlamos todos nuestros objetos creados por dabase. Y solo para mantener a los desarrolladores honestos (porque puede crear objetos sin que estén en Source Control), nuestros dbas buscan periódicamente cualquier cosa que no esté en control de la fuente y, si encuentran algo, lo abandonan sin preguntar si está bien.

Nunca debe iniciar sesión y comenzar a ingresar los comandos "ALTER TABLE" para cambiar una base de datos de producción. El proyecto en el que estoy tiene una base de datos en cada sitio de clientes, por lo que cada cambio en la base de datos se realiza en dos lugares, un archivo de volcado que se utiliza para crear una nueva base de datos en un sitio de clientes nuevo y un archivo de actualización que se ejecuta en cada actualización que verifique el número de versión de su base de datos actual con el número más alto en el archivo, y actualice su base de datos en su lugar. Así, por ejemplo, las últimas actualizaciones:

if [ $VERSION /< ''8.0.108'' ] ; then psql -U cosuser $dbName << EOF8.0.108 BEGIN TRANSACTION; -- -- Remove foreign key that shouldn''t have been there. -- PCR:35665 -- ALTER TABLE migratorjobitems DROP CONSTRAINT migratorjobitems_destcmaid_fkey; -- -- Increment the version UPDATE sys_info SET value = ''8.0.108'' WHERE key = ''DB VERSION''; END TRANSACTION; EOF8.0.108 fi if [ $VERSION /< ''8.0.109'' ] ; then psql -U cosuser $dbName << EOF8.0.109 BEGIN TRANSACTION; -- -- I missed a couple of cases when I changed the legacy playlist -- from reporting showplaylistidnum to playlistidnum -- ALTER TABLE featureidrequestkdcs DROP CONSTRAINT featureidrequestkdcs_cosfeatureid_fkey; ALTER TABLE featureidrequestkdcs ADD CONSTRAINT featureidrequestkdcs_cosfeatureid_fkey FOREIGN KEY (cosfeatureid) REFERENCES playlist(playlistidnum) ON DELETE CASCADE; -- ALTER TABLE ticket_system_ids DROP CONSTRAINT ticket_system_ids_showplaylistidnum_fkey; ALTER TABLE ticket_system_ids RENAME showplaylistidnum TO playlistidnum; ALTER TABLE ticket_system_ids ADD CONSTRAINT ticket_system_ids_playlistidnum_fkey FOREIGN KEY (playlistidnum) REFERENCES playlist(playlistidnum) ON DELETE CASCADE; -- -- Increment the version UPDATE sys_info SET value = ''8.0.109'' WHERE key = ''DB VERSION''; END TRANSACTION; EOF8.0.109 fi

Estoy seguro de que hay una mejor manera de hacerlo, pero hasta ahora me ha funcionado.

RedGate es excelente, generamos nuevas instantáneas cuando se realizan cambios en la base de datos (un pequeño archivo binario) y mantenemos ese archivo en los proyectos como un recurso. Siempre que necesitemos actualizar la base de datos, usamos el kit de herramientas de RedGate para actualizar la base de datos, además de poder crear nuevas bases de datos a partir de las vacías.

RedGate también hace instantáneas de datos, aunque personalmente no he trabajado con ellas, son igual de robustas.

Requerir que los equipos de desarrollo utilicen un sistema de gestión de control de fuente de base de datos SQL no es la solución mágica que evitará que ocurran problemas. Por sí solo, el control de origen de la base de datos introduce una sobrecarga adicional, ya que los desarrolladores deben guardar los cambios que han realizado en un objeto en un script SQL separado, abrir el cliente del sistema de control de origen, verificar el archivo de script SQL usando el cliente y luego Aplicar los cambios a la base de datos en vivo.

Puedo sugerir usar el complemento SSMS llamado ApexSQL Source Control . Permite a los desarrolladores asignar fácilmente objetos de base de datos con el sistema de control de origen a través del asistente directamente desde SSMS. El complemento incluye soporte para TFS, Git, Subversion y otros sistemas SC. También incluye soporte para fuente de control de datos estáticos.

Después de descargar e instalar ApexSQL Source Control, simplemente haga clic con el botón derecho en la base de datos que desea controlar la versión y navegue hasta el submenú de ApexSQL Source Control en SSMS. Haga clic en la opción Vincular base de datos a control de origen, seleccione el sistema de control de origen y el modelo de desarrollo. Después de eso, deberá proporcionar la información de inicio de sesión y la cadena de repositorio para el sistema de control de origen que ha elegido.

Puede leer este artículo para obtener más información: http://solutioncenter.apexsql.com/sql-source-control-reduce-database-development-time/

Sí, creo que es importante para la versión de su base de datos. No los datos, pero el esquema para cierto.

En Ruby On Rails, esto es manejado por el marco con "migraciones". Cada vez que modifica la db, crea un script que aplica los cambios y lo marca en el control de origen.

A mi tienda le gustó tanto esa idea que agregamos la funcionalidad a nuestra compilación basada en Java usando shell scripts y Ant. Integramos el proceso en nuestra rutina de despliegue. Sería bastante fácil escribir scripts para hacer lo mismo en otros marcos que no sean compatibles con la versión de DB fuera de la caja.

Sí, lo hacemos manteniendo nuestro SQL como parte de nuestra compilación: mantenemos DROP.sql, CREATE.sql, USERS.sql, VALUES.sql y la versión de estos, para que podamos volver a cualquier versión etiquetada.

También tenemos tareas de hormigas que pueden recrear la base de datos cuando sea necesario.

Además, el SQL se etiqueta junto con el código fuente que lo acompaña.

Sí. El código es el código. Mi regla de oro es que necesito poder compilar e implementar la aplicación desde cero , sin mirar una máquina de desarrollo o producción.

Si siempre Debería poder recrear la estructura de su base de datos de producción con un conjunto útil de datos de muestra cuando sea necesario. Si no lo hace, con el tiempo los cambios menores para mantener las cosas en funcionamiento se olvidan, entonces un día, lo mordemos a lo grande. Es un seguro que tal vez no creas que necesitas, pero el día que lo hagas, ¡vale la pena el precio 10 veces más!

Si su base de datos es SQL Server, podríamos tener la solución que está buscando. SQL Source Control 1.0 ahora ha sido lanzado.

http://www.red-gate.com/products/SQL_Source_Control/index.htm

Esto se integra en SSMS y proporciona el pegamento entre los objetos de su base de datos y su VCS. El ''scripting out'' ocurre de forma transparente (utiliza el motor de comparación de SQL bajo el capó), lo que debería hacer que su uso sea tan sencillo que los desarrolladores no se desanimen a adoptar el proceso.

Una solución alternativa de Visual Studio es ReadyRoll , que se implementa como un subtipo del Proyecto de Base de Datos SSDT. Esto requiere un enfoque impulsado por las migraciones, que es más adecuado para los requisitos de automatización de los equipos de DevOps.

Tengo todo lo necesario para recrear mi DB a partir de metal desnudo, menos los datos en sí. Estoy seguro de que hay muchas formas de hacerlo, pero todos mis scripts y los demás están almacenados en Subversion y podemos reconstruir la estructura de la base de datos y demás extrayendo todo eso de Subversion y ejecutando un instalador.

Utilizo SchemaBank para controlar la versión de todos los cambios de esquema de mi base de datos:

  • desde el día 1, importo mi esquema de db dump en él
  • Comencé a cambiar el diseño de mi esquema usando un navegador web (porque están basados ​​en SaaS / cloud)
  • cuando quiero actualizar mi servidor db, genero el script de cambio (SQL) y lo aplico a la db. En Schemabank, me obligan a comprometer mi trabajo como una versión antes de que pueda generar un script de actualización. Me gusta este tipo de práctica para poder siempre rastrear cuando lo necesito.

La regla de nuestro equipo NUNCA toque el servidor db directamente sin almacenar primero el trabajo de diseño. Pero sucede, alguien podría estar tentado a romper la regla, por conveniencia. Importaríamos el volcado de esquema nuevamente en schemabank y dejaríamos que hiciera la diferencia y golpearía a alguien si se encuentra una discrepancia. Aunque podríamos generar las secuencias de comandos de modificación para sincronizar nuestro diseño de db y esquema, simplemente lo odiamos.

Por cierto, también nos permiten crear sucursales dentro del árbol de control de versiones para que pueda mantener una para la puesta en escena y otra para la producción. Y una para la codificación del arenero.

Una herramienta de diseño de esquema basada en web bastante ordenada con control de versiones y gestión de cambios.

Utilizo los scripts SQL CREATE exportados desde MySQL Workbech, luego, utilizando su funcionalidad "Exportar SQL ALTER", termino con una serie de scripts de creación (numerados, por supuesto) y los scripts de modificación que pueden aplicar los cambios entre ellos.

3.- Exportar script ALTER de SQL Normalmente normalmente tendría que escribir las sentencias ALTER TABLE a mano ahora, reflejando los cambios que realizó en el modelo. Pero puede ser inteligente y dejar que Workbench haga el trabajo duro por usted. Simplemente seleccione Archivo -> Exportar -> Secuencia de comandos ALTER SQL de Forward Engineer ... desde el menú principal.

Esto le pedirá que especifique el archivo SQL CREATE con el que se debe comparar el modelo actual.

Seleccione la secuencia de comandos CREAR de SQL desde el paso 1. La herramienta generará la secuencia de comandos ALTER TABLE por usted y puede ejecutar esta secuencia de comandos contra su base de datos para actualizarla.

Puede hacer esto utilizando el buscador de consultas MySQL o el cliente mysql. ¡Tu modelo y base de datos ya han sido sincronizados!

Fuente: MySQL Workbench Community Edition: Guía para la sincronización de esquemas

Todos estos scripts, por supuesto, están dentro del control de versiones.

Yo controlo el esquema de la base de datos mediante una secuencia de comandos de todos los objetos (definiciones de tablas, índices, procedimientos almacenados, etc.). Pero, en cuanto a los datos en sí, simplemente confíe en las copias de seguridad regulares. Esto garantiza que todos los cambios estructurales se capturen con el historial de revisión adecuado, pero no carga la base de datos cada vez que cambian los datos.