Desarrollo ágil y cambios en la base de datos

Question

Para aquellos profesionales ágiles que existan ...

¿Cómo se gestionan los cambios en el esquema de una base de datos durante un proyecto? Mi suposición es que en un proyecto ágil, el esquema de cualquier base de datos involucrada cambiará y se refactorizará tal como sucede con la base de código.

¿Es correcta esta suposición? Si es así, ¿tiene alguna herramienta o proceso en particular que use para ayudar a que las cosas funcionen sin problemas?

Answer 1

AgileData.org es un recurso excelente, mucho más de lo que incluyo en una sola respuesta, en el desarrollo de la base de datos Agile. En particular, puede que le interese Agile Data Best Practices. Si utiliza SQL Server, también podría estar interesado en SQL Compare del software Red Gate. Nuestros DBA lo han usado para ayudarme a migrar los cambios de control de calidad a producción para las aplicaciones existentes.

Answer 2

Lo ideal es que realice cambios sin interrupciones, y cuando se haya realizado la liberación puede descartar por completo las partes antiguas del esquema. Esto no es fácil y requiere disciplina. Ni siquiera es siempre posible.

Answer 3

Eche un vistazo a Ruby on rails migrations. No importa si no usa Rails, ya que la idea ya se ha copiado a otro framework.

Answer 4

En nuestra configuración Agile, hay una carpeta para cambios de base de datos, hechos como archivos .SQL. Hasta el momento hemos tenido un cambio en la base de datos en cada versión, y el nombre del archivo viene después de la versión de la aplicación. El script de instalación aplica automágicamente todos los archivos de cambio al actualizar los sitios.

También tenemos un volcado de esquema completo de un DB de referencia, que se utiliza para nuevas instalaciones, creado por nuestra herramienta de administración de bases de datos.

Sé que hay herramientas que ayudan a automatizar este proceso, como Red Gate, pero crear manualmente el archivo de cambio de SQL es muy fácil.

Answer 5

Para cada actualización, sería:

• despliegue de la puesta al día y los guiones de rollback,
• el despliegue de un guión "construir la base de datos desde cero",
• desplegar un script de migración de datos, y
• aplicando un mecanismo mediante el cual el código está bloqueado a la versión de la base de datos, es decir, probando un valor que devuelve la versión actual del DB; si hay una discrepancia, el sistema suelta y balbucea ruidosamente sobre la falta de coincidencia.

HTH

aplausos,

Rob

Answer 6

La estructura de base de datos es más probable que sea una dependencia de muchas partes de su código, y los cambios de esquema tendrá efectos en cascada. Algo así como hacer cambios en la interfaz en una clase que muchas clases extienden. Así que tenga cuidado con los cambios de esquema.

La metodología Ágil no es diferente de otras metodologías, ya que es en su beneficio diseñar la base de datos por adelantado tanto como sea posible, y debería intentar cambiarla con menos frecuencia que el código. No quiere decir que nunca puedas cambiarlo, pero es costoso hacerlo.

Las migraciones son una herramienta simple pero efectiva para rastrear cambios en el esquema, como han notado otros. El concepto es scripts de las sentencias CREATE y ALTER para actualizar de una revisión del esquema a la siguiente, acompañada de scripts de las sentencias ALTER y DROP para degradar los mismos cambios. Ruby on Rails utiliza una capa de abstracción de base de datos además de esto para facilitar el cambio de marcas de bases de datos, pero si solo necesita admitir una marca, simplemente podría usar archivos SQL.

Hay un libro muy respetado sobre este tema (aunque no he tenido tiempo de comprar o leer todavía) llamado "Refactoring Databases: Evolutionary Database Design" por Scott Ambler