Es muy común que los equipos de desarrollo trabajen sobre un ambiente de base de datos compartido. ¿Quién no ha sufrido las consecuencias de los desfasajes entre *la* base de datos y el resto del proyecto? ¿Quién no ha sido víctima –o victimario– de algún improperio cuando, en pleno desarrollo, un cambio en alguna propiedad u objeto de la base deja al resto del código pataleando en el aire?
Nunca, desde mis tempranos inicios, a través de diferentes proyectos en varias compañías, tuvieron estas cuestiones la suficiente importancia como para quitarle el sueño a nadie. Siempre, esto es lo realmente grave, parecieron ser lo normal. Estaba ante una enfermedad crónica.
Desarrollar implica agregar código, depurar, refactorizar y repetir estas operaciones un número de veces hasta obtener una determinada pieza de software. A nadie se le ocurre, hoy en día, que no se disponga de un sistema de control de código fuente, que permita a cada integrante del equipo trabajar localmente y luego, una vez concluida la construcción de la pieza, incorporar sus cambios al repositorio común.
Cada desarrollador debe trabajar en su propio espacio. Siguiendo esta premisa, ¿por qué la base de datos, siendo parte esencial del producto, no se incluye en él? ¿Por qué no es natural que cada desarrollador trabaje sobre su propio ambiente de base de datos?
Surge un problema. Si cada programador opera sobre su propio ambiente, ¿cómo obtienen los demás integrantes del equipo las modificaciones al esquema realizadas localmente? Del mismo modo que lo hace con el resto del código de la aplicación: mediante el repositorio de código fuente.
Por ello es indispensable que los scripts de base de datos estén incluidos en el controlador de código fuente, al igual que todo el resto del código. Es a través de estos scripts que se deben formalizar los cambios en la base que completan la programación de una pieza de software.
La base de datos, a diferencia de una pieza de código común, contiene estado (para eso está). Por eso, además del código para la creación de sus objetos, se deben tener en cuenta scripts de inserción de datos básicos para la aplicación (tablas paramétricas, tablas maestras) y, eventualmente, algún pequeño set de datos de prueba.
…continuará…
(*) Andrés dice: por fin, y luego de dos años de arrastrarme, alguien ha escuchado mis ruegos, dignándose a brindar… ¡una colaboración! Y en buena hora, que en este lugar ya se empezó a juntar el polvo. Esperemos que sea la primera de una larga serie y dé comienzo a una maratón de talentosos desarrolladores ansiosos por ayudarme a mantener vivo este humilde espacio (esperar es gratis, dicen).
3 comentarios:
es un punto importante y que en nuestro trabajo (Servicio Salud O'Higgins) hemos incorporado como práctica, los parches de sw o nuevos requerimientos que requieran modificaciones a la bd implican la generaciòn de los scripts respectivos para replicar estos cambios en los diferentes ambientes... y obviamente hasta los scripts con cargas de datos masivos estàn incorporados en nuestro control de còdigo fuente (GIT).
Edward, está muy bien.
Nosotros, particularmente, utilizamos otro approach. No creamos manualmente scripts de actualización de BD, sino que modificamos siempre los scripts de creación, los originales. Al momento de implementar actualizaciones, obtenemos los delta (hay muchas herramientas que brindan esta funcionalidad) entre dos esquemas de base de datos (el productivo y el que se quiere implementar). Cada implementación está identificada en nuestro repositorio de código fuente con un Label (o Branch segun corresponda) lo que nos permite obtener la versión de los scripts de base de datos que necesitemos.
Estas cuestiones las abordaremos con mas detalle en los siguientes posts referidos al tema.
Martín.
Estoy esperando una nueva entrada. Este blog es realmente muy educativo, al menos para los que no somos del palo. Y lo mejor es que se aprende a través del humor. Que no se caiga!!
Ildag Boan
Publicar un comentario