Desplegando con Integration Services

Para los que tengáis experiencia desplegando aplicaciones o actualizaciones de las mismas en cliente, tendréis más que vista la problemática que supone el despliegue de los scripts con las actualizaciones de la base de datos. Dependiendo del tamaño del despliegue os podéis plantar con un script para lanzar o con decenas o cientos de ellos, y cuantos más tengamos, más aumenta la probabilidad de que ocurra un error.
Los scripts de actualización de base de datos tienen varios problemas principales:
1) Deben lanzarse en el orden correcto. Por ejemplo, como se os ocurra hacer una modificación de una tabla que aíºn no habéis creado, fallará.
2) Como te dejes un script por pasar, no te vas a enterar seguramente hasta que la aplicación intente actualizar una tabla, o un campo que supuestamente deberí­a existir.
3) Si lanzas el script en la base de datos que no toca, puede que no de error, pero cuando la aplicación se ejecute sobre la base de datos va a darte el mismo problema que en el punto 2.
4) Normalmente los scripts de actualización no los vas a lanzar tíº, si no una tercera persona, por lo que al no tener control sobre ello debes dar por hecho que el error puede ocurrir… y si puede ocurrir… ocurrirá.
5) En caso de error o de querer retornar al estado anterior, deberás tener preparados los scripts de vuelta atrás (también se les llama contramedidas). Lanzando los scripts de vuelta atrás puedes tener los mismos problemas que los puntos 1, 2, 3 y 4.
Y ahora la pregunta del millón, ¿hay alguna forma de minimizar estos riesgos? Afortunadamente sí­.
No sé si conocéis Integration Services, es una de las herramientas de integración de datos que provee SQL Server 2005. Sirve para muchas cosas, mantenimiento de bases de datos, creación de ETL’s, y mira tíº por donde, podemos usar su potencia para desplegar scripts para el cliente.
Una de las principales ventajas de Integration es que funciona como un motor de flujo, donde nosotros vamos indicando el inicio del flujo, las actividades que forman parte de él y la forma en la que se relacionan.
íšnicamente ya al tratarse como un motor de flujo tenemos resuelto uno de los principales problemas, la secuencialidad. Seguro que se ejecutan los scripts en el orden correcto ya que de eso se va a encargar el motor de flujo (si es que hemos definido bien el flujo claro).
Otro de los grandes problemas que se solucionan es que a la hora de que lance la actualización esa tercera persona, seguro que va a lanzar lo mismo exactamente que has probado tíº, ya que va a lanzar un paquete entero que internamente va a lanzar los scripts para los que haya sido preparado. Este mismo problema se soluciona en el caso de querer lanzar los scripts de vuelta atrás.
Eso sí­, el tema de dejarte un script sin definir eso no lo resuelve nadie. Si en desarrollo modificaste una tabla y no dejaste constancia en ningíºn lado, cuando hagas el paquete de integration no reflejarás el cambio, por lo que la base de datos de producción no estará en consonancia con la tuya, y, entonces, fallará.
Finalmente otros temas a discutir aquí­ que suponen mejoras añadidas, valores no tangibles, son los siguientes:
1) Es mucho más fácil de mantener y desarrollar un paquete de integration que un archivo sql con 800 scripts sueltos dentro.
2) El minimizar los problemas en el despliegue aumenta la calidad de tu producto.
3) Tu imagen cara al cliente se ve mejorada, no es lo mismo entregar 20 scripts que un paquete de integration. Lo segundo da una imagen más profesional y controlada.
Saludos.
Miguel.