Tu base de datos es como tu ropa interior, no se comparte.

por Publicado el

Las bases de datos son las grandes olvidadas a la hora de trabajar con aplicaciones, sobre todo legado. Una base de datos productiva tiende a crecer, no solo en los datos que almacena, ni en los recursos que ocupa, eso se asume y se espera por el equipo de desarrollo. Por crecimiento, me refiero al de los objetos y componentes que se van incorporando  por los programadores (esquemas, usuarios, tablas, vistas, procedimientos almacenados, etc. ). A continuación te explico por qué deberías prestarle más atención a tu base de datos en la construcción de tus sistemas.

La base de datos no se comparte con cualquier sistema o cualquier programador.

Tu base es un recurso valioso que puede ser dañado o lisiado por alguien que no tengo el mismo cuidado que tu. Construir un sistema que se cuelgue de una base de datos ajena genera un conflicto de intereses. El sistema original tiene sus propios intereses y sus propias razones de cambio. Al incrustar otro sistema, que  a su vez tiene sus propios intereses y sus propias razones de cambio, lo único que conseguirás será agregar complejidad innecesaria a tus aplicaciones. Si en algún momento alguien te plantea como solución fácil conectarse directamente a tu base, piénsalo. Puede salirte más caro de lo que crees. Es mejor usar capas de abstracción que permitan la comunicación entre sistemas sin tocar directamente la base.

Una única base para gobernar a tus programadores. Cuando tu base de QA es comunitaria.

Es fácil detectar las amenazas externas, estas también pueden estar dentro del equipo. Una práctica común en la empresa es tener una base de datos «cajón de arena» donde trabaja el equipo. Todo el equipo tiene los permisos para modificar y eso termina sucediendo, todos le meten mano. Pruebas de concepto, prototipos, datos, basura, proyectos que no llegaron a término, etc.  Todo esto se va sumando a la base y la hace difícil de mantener, con el paso del tiempo se termina teniendo bases de datos que se parecen, pero no son idénticas entre ambientes. Cualquier cambio por más sencillo que sea debe ser tratado como una migración debido a la complejidad generada.

Un programador, una base de datos.

Cada miembro del equipo debe tener una copia de la base con la que pueda trabajar. Nunca va a ser buena idea compartir, aun entre el equipo. Esto obliga a cada programador a llevar un control estricto de los cambios o datos de sus actividades. El compromiso se vuelve mayor que si solo existiera una base comunitaria, por ejemplo:  un fallo en la creación de un script de una liberación tiene un responsable directo. Puede ser un problema de orden de liberaciones, error humano,  diferencias en la base. Va a resultar más complicado acusar a la base de QA o de producción por algún fallo.

Debe de existir una autoridad de base de datos.

Para evitar la anarquía en las bases, tu equipo debe nombrar a un responsable. Un filtro que ejecute y administre los cambios y migraciones, no tiene que ser una persona fija. El rol puede ser rotativo entre el equipo, lo importante es que transmitas el mensaje de que no cualquiera persona, ni en cualquier momento se puede modificar la base. Con estas prácticas generas un círculo virtuoso, el equipo toma consciencia sobre  la importancia de la homologación, y reduces las posibilidades de fallo. Sí, es fácil  de decir, difícil de implementar. Debes tener en cuenta que cualquier tratamiento preventivo siempre te saldrá más barato que su contraparte correctiva.

No hay herramientas que sirvan si no hay un proceso.

Existen herramientas que te permiten acelerar o incluso hacer el trabajo de homologar y administrar bases. No hablo de eso, cualquier herramienta es inútil si no hay compromiso de parte del equipo con la calidad en sus bases. Por eso, es valioso trabajar el proceso, y por proceso me refiero a las actividades que realizan las personas. Todo el equipo debe tener claro cuáles son los pasos para liberar cambios en los ambientes, los pasos deben de ser repetibles por cualquier programador. Una vez que quedo claro el procedimiento y es aplicado por el equipo ya podemos hablar de automatizar o usar herramientas que hagan el trabajo.

Autor imagen: Leslie B Jones

 

Gustavo Sánchez
Últimas entradas de Gustavo Sánchez (ver todo)

Publicado por Gustavo Sánchez

Soy especialista en escribir software de calidad. Mediante el uso de marcos de trabajo, técnicas y automatización de procesos he podido reducir los costes operativos de los sistemas de la empresa. Sistemas confiables y adaptables producen clientes felices.