Integración continua y administración de base de datos

Question

Al trabajar en un proyecto con varias personas más, es común tener varias personas con áreas diferentes, como la base de datos.

Mi desafío es cómo permitir que varias personas editen el modelo de base de datos en un entorno de integración continua.

Un desarrollador sugirió escribir un "script de control de versiones" donde cada edición se ingresaba en un script .sql, con un número de versión que la base de datos podría detectar. Una nueva adición al modelo en este archivo se etiquetaría con una versión, y la base de datos se actualizaría una vez que se hubiera enviado el script y se hubiera ejecutado una compilación.

También he oído hablar de Publisher/Subscriber ... y leí un poco al respecto.

¿Cómo maneja esta situación en su trabajo diario, y qué sugerencias me puede dar para hacer que los cambios en la base de datos se desarrollen lo más fácilmente posible?

** se han mencionado Editar **

marcos de migración y migración-scripts. Si tiene alguna experiencia práctica y sugeriría un marco, eso también sería apreciado.

Answer 1

Citando Jeff Atwood en el excelente Get Your Database Under Version Control mensaje:

...

Estaba pensando en esto de nuevo porque mi amigo y co-author K. de Scott Allen acaba de escribir un brillante de cinco partes serie en la filosofía y práctica de control de versión de base de datos:

1. Three rules for database work
2. The Baseline
3. Change Scripts
4. Views, Stored Procedures and the Like
5. Branching and Merging

...

En realidad, toda la serie es vale la pena leer, aunque muchos de los que parece haber especialmente interesado por la tercera parte. Y por cierto, eche un vistazo al artículo Bulletproof Sql Change Scripts Using INFORMATION_SCHEMA Views mencionado en la tercera parte también. Es posible que ya lo sepa, pero explica, entre otras buenas prácticas, por qué es importante escribir las secuencias de comandos de cambio idempotent.

En cuanto a las herramientas, es posible que desee comprobar hacia fuera UpToDater (centrada en el código), LiquiBase (XML basado) o ... dbdeploy, una pequeña joya basado en las experiencias del mundo real de desarrollo de software en ThoughtWorks. No es que los 2 primeros no sean buenos, pero este es mi preferido (y está disponible para Java, PHP o .NET).

Answer 2

Echa un vistazo a los marcos de migración. AFAIK, la idea provino de los rieles, pero la gente ha construido marcos para casi todo lo demás en este punto.

Answer 3

Tiendo a funcionar mejor con scripts de "migración", que son el siguiente paso desde un script de versión simple. Con una migración, especifica los cambios en la base de datos (adiciones, eliminaciones, etc.) y también cómo deshacer los cambios que está realizando su migración. Esto se etiqueta con una versión de alguna forma que no entrará en conflicto con otros desarrolladores. Un número de versión particularmente bueno es la hora actual (en formato YYYYMMDDHHMMSS o tan solo como segundos de la época). Esta es una buena opción porque es muy poco probable que tenga conflictos de versiones y todavía es muy fácil ver si existen nuevas versiones debido a la naturaleza estrictamente creciente de tales marcas de tiempo.

Nota: Esto está muy influenciado por el sistema de migración en Rails. Para obtener más detalles e ideas, le recomiendo que investigue ese sistema. la migración

Rieles:

class CreateGroups < ActiveRecord::Migration 
    def self.up 
    create_table :groups do |t| 
     t.string :name 
     t.references :owner 

     t.timestamps 
    end 
    end 

    def self.down 
    drop_table :groups 
    end 
end 

Doctrina de migración:

class CreateGroups extends Doctrine_Migration 
{ 
    public function up() 
    { 
     // Create new author table 
     $columns = array('id' => array('type'   => 'integer', 
             'length'  => 4, 
             'autoincrement' => true), 
         'name' => array('type'   => 'string', 
             'length'  => 255), 
         'owner_id' => array('type' => 'integer', 
              'length' => 4)); 

    $this->createTable('groups', $columns, array('primary' => array('id'))); 
    } 

    public function down() 
    { 
    $this->dropTable('groups'); 
    } 
} 

(lo siento por la falta de marcas de tiempo en la doctrina ... en los carriles de la llamada marcas de tiempo se suma en created_at y updated_at campos a la tabla que se administran automáticamente para usted. No estoy seguro de un comportamiento similar en la doctrina, así que los dejé fuera).

Answer 4

Depende.

Si se trata de un producto lanzado, las ediciones de esquemas deberían rastrearse cuidadosamente para que pueda planificar su proceso de actualización. Sería bueno comenzar a pensar en eso ahora, por lo que el "guión de control de versiones" tiene cierto nivel de sentido. Pero la compatibilidad hacia adelante/atrás suele ser solo un requisito visible para el usuario, no un requisito de "entre compilaciones". Entre lanzamientos, tendría sentido mantener un script de actualización que modifique las tablas de la base de datos para llevarlo al nuevo esquema.

Si este es un producto nuevo/inédito, ¿qué le importa si alguien cambia el esquema?¿Y por qué querrías mantener la base de datos entre compilaciones de integración continua? Deberías poder regenerar cualquier dato de prueba con una prueba automatizada, de todos modos. Sin embargo, cualquiera que cambie el esquema debería actualizar las pruebas.

Para un producto lanzado, es probable que desee tener un conjunto de pruebas que puedan tratar con una base de datos "versión 1.0", para asegurarse de que pueda actualizarse satisfactoriamente a la "versión 1.1" (por ejemplo).

Answer 5

Escrituramos todo en Subversion y lo registramos en el proyecto como cualquier otro código. Todas las implementaciones de bases de datos se realizan desde scripts extraídos del sistema de control de origen. Si dos personas trabajan en la misma secuencia de comandos (lo cual es bastante raro), Subversion le permitirá fusionar las dos secuencias de comandos.

Answer 6

La pila de tecnología (incluida la base de datos utilizada) no se describió en la pregunta, que es muy relevante para la solución más adecuada.

Una solución muy popular de migraciones centradas en Java es Flyway. DBUp es muy similar, pero se centra en la pila .NET.

Aquí en Redgate ofrecemos ReadyRoll, que se integra perfectamente en Visual Studio y funciona exclusivamente en SQL Server.