Parches y soluciones

Allá lejos y hace tiempo, en el primer post de este blog describía el proceso de desarrollo de software como un sistema. Un sistema (administrativo) que produce sistemas (informáticos).

Los refiero a ese artículo antes de leer lo que sigue. Sólo quiero remarcar que señalaba que la retroalimentación de ese sistema era la actividad de examinar el proceso mismo en aras de mejorarlo continuamente.

Dentro de este sistema de desarrollo puede pensarse en un parche y una solución para cada problema (estoy inventando terminología, no me maten). El parche es la actividad que resuelve la situación puntual, mientras que la solución es un cambio en la metodología de trabajo o en el circuito administrativo dentro del equipo que torna imposible la situación que originó el error. Esto que parece bastante abstracto surge fácilmente con un ejemplo:

Error: la estructura de la base de datos en producción no coincide con la estructura en desarrollo.

Parche: se ingresa un ticket de incidente para los administradores de la base de datos para que corrijan las desviaciones detectadas.

Solución: ¿?

El parche es obvio, la solución no tanto. Solucionar el problema en el sentido que planteo en este artículo requiere de un profundo análisis previo y cambios que probablemente afecten a varios equipos o áreas dentro de la empresa, cuestión para nada sencilla. Lo que sigue es una solución que surgió en mi equipo de trabajo para este tipo de problemas. Verán que no es perfecta, ninguna lo es.

Comenzamos por la pregunta: ¿cómo es posible que la base de datos de producción difiera de la de desarrollo? Comentando el proceso de instalación nos enteramos de que para instalar el software se toman los ensamblados de una carpeta X y la base de datos de...

Para nuevas instalaciones, de una copia de la base de datos de desarrollo, "limpiada" (borrados los datos de prueba).

Para actualizaciones, se toman el conjunto de scripts de cambio, creados por los desarrolladores al implementar cada fix. Recalquemos esto: cada desarrollador que necesitaba un cambio en la base de datos modificaba la base de desarrollo y archivaba el script de actualización.

La documentación (el DER) de la base de datos se utilizaba sólo como documentación de referencia, y era actualizado de vez en cuando, a partir de la base de datos de desarrollo.

En este esquema es fácil ver cómo puede darse el error del que hablábamos: si un desarrollador olvida crear el script de cambio, por ejemplo, la base en producción no se actualiza. Si los administradores toman la base de datos de desarrollo a destiempo, un poco antes o después de congelar la versión, podría no estar sincronizada con la versión recién congelada.

Luego de muchos meses de pequeños ajustes, idas y vueltas, pruebas y errores, llegamos a lo siguiente:

Cualquier base de datos "nueva" es creada por los administradores de base de datos a partir del DER, con una herramienta.

Los scripts de actualización para cada versión surgen de la comparación automática (con la herramienta mencionada arriba) entre el DER de la versión y la base de datos real de la instalación que se pretende actualizar (es decir, hay un script para cada actualización en particular).

Los desarrolladores modifican la estructura de la base de datos y envían un reporte del cambio a los administradores de bases de datos, que actualizan el DER. Al cerrar una versión se compara el DER contra la base de desarrollo (deberían ser iguales). Si hay diferencias se busca entre los reportes de cambio para corregir el error.

Si revisamos el esquema de trabajo mencionado vemos que de cumplirse las diferencias entre producción y desarrollo son imposibles, o a lo sumo fácilmente corregibles (aplicando el DER de la versión a cada base en particular).

Las soluciones siempre estarán más ligadas a lo administrativo que a lo técnico, y por la experiencia que tuve, es más que común que sea algún tipo de variación del viejo principio de control por división de tareas, que en muchos equipos se vulnera: "El que hace no registra, el que registra no hace". El contador registra, el tesorero maneja el dinero. Ventas/cobranzas deben ser departamentos separados, compras/pagos también. En nuestro caso: el que aplica el cambio en la base (el desarrollador) no lo registra. Otros ejemplos clásicos del mundo del desarrollo: los desarrolladores no prueban, los administradores no instalan, los analistas no implementan, etc.

Siguiendo nuestra nueva terminología, las metodologías de desarrollo (desde el tradicional ciclo de vida hasta la Programación Extrema) presentan circuitos administrativos evolucionados a lo largo del tiempo para minimizar la cantidad y gravedad de errores que pueden producirse. Pero recordemos que así como es impensable para cualquier equipo implementar metodologías a rajatabla (es decir, sin ningún tipo de adaptación a la situación en particular) las soluciones reales necesariamente deben variar de acuerdo a cada equipo, y lo que funcione para uno no necesariamente funcionará para el otro. Aquí es donde entran a jugar muchos otros factores, tales como la cultura, la formación, el liderazgo, etc.