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.
Hoy en el blog abrimos otra lata más, en lo que será un conjunto de posts al respecto de los despliegues de aplicaciones.
No vamos a aprender a desplegar aplicaciones de una tecnología en concreto, si no que se va a tener en cuenta otros principios básicos sobre los despliegues, ideas de cómo enfocarlos, como ejecutarlos, cómo organizar los documentos de despliegue, y otras ideas de cómo conseguir minimizar los tiempos, aumentar la calidad, etc.
Como aperitivo respecto a este tema, me gustaría dejar algunas reflexiones al respecto:
1) Tal vez tu cliente no vea nunca una línea de tu código, pero seguro que se lee el documento de despliegue, y además, será la primera toma de contacto real con tu producto.
2) Los despliegues también se tienen que probar. Probar un despliegue en un entorno que no tiene que ver con el real no te va a servir de nada.
3) Ten en cuenta que el departamento de sistemas de tu cliente va a querer tener muy claro qué es lo que vas a desplegar. El despliegue no sólo afectará al departamento de desarrollo.
4) Las diferentes tecnologías de desarrollo disponen de productos que ayudan a preparar despliegues, tal vez debas dedicar algo de tiempo a investigar al respecto.
5) Cada uno de tus despliegues no es algo independiente en la vida de tu producto. Podrás aplicar la reutilización, la mantenibilidad y el aumento de valor también en tus despliegues. Aprende de tus despliegues y aumenta tu conocimiento.
6) Es una pena que con el trabajo que te ha llevado que tu aplicación funcione en las máquinas de desarrollo, no funcione en pre-producción porque no has sido capaz de definir bien el despliegue. Si no funciona en pre-producción tu trabajo no vale para nada.
7) Si tras el despliegue no eres capaz de retornar la aplicación a su estado inicial, la llevas clara.
Los campos nullables surgen en .NET por la necesidad de disponer, entre otros, de campos date, int y long que admitan valores nulos. En principio, y si no se indica lo contrario, un entero que no ha sido inicializado tendrá el valor cero. Esto puede resultar un problema, por ejemplo en casos de que necesitemos disponer de una variable entera con un valor nulo.
Otro de los problemas que puede tener la inicialización a cero de un entero es que si vemos su valor a cero podemos no saber si es porque no se ha inicializado o porque se le ha asignado dicho valor.
Un string, es nullable de por sí, no hace falta indicarlo explícitamente.
Como ejemplo, para que un campo sea nullable en C# se debe concatenar “?” a la declaración del tipo del campo.
Como es costumbre, con los cursos que he ido realizando desde la apertura del blog, dejo aquí un pequeño resumen.
Hace ya dos semanas que estuve asistiendo en Madrid a un Curso de Business Intelligence. El curso fue de 50 horas de duración y ha surgido por la promoción del area de formación de la empresa en la que ahora mismo trabajo.
La verdad es que ha sido bastante interesante, pudimos ver cómo resuelve Microsoft el área de Business Intelligence mediante los productos Integration Services, Analisis Services y Reporting Services. Además, tuvimos la oportunidad de repasar muchas funcionalidades de SQL Server 2005, en concreto temas de optimización.
Destacar sobre todo la potencia que ofrece Integration Services para el manejo de ETL’s (ya hemos hablado de esto en otra ocasión en este mismo blog), prometo un día de estos hacer un enfoque algo más profundo al tema.
En cuanto a Reporting Services… es como Crystal Reports, pero integrado en SQL Server 2005
Analisis Services… toda la gestión de Data Mining, Cubos, Tablas de Hechos, Tablas de Dimensiones…
Por temas laborales últimamente estoy teniendo contacto con proyectos donde participan un alto número de programadores con poquita experiencia o chicos y chicas con una beca y que dan sus primeros pasos en este mundo recién acabada la carrera o con alguna asignatura aún pendiente.
La verdad es que aunque parezca contradictorio estoy aprendiendo muchísimo de ellos, una cosa es que tengan poquita experiencia laboral y otra que no sepan de qué va esto y qué es lo que quieren. Está siendo una experiencia realmente gratificante.
Tras la puesta en situación me pongo ya con el tema principal del post que es sobre el debug. La verdad es que una de las cosas que estoy viendo al respecto de este perfil de profesional que antes comentaba, es que salen de sus carreras, modulos o estudios varios correspondientes sin que nadie les haya contado lo que es un debug, cosa que, sinceramente, no es que me sorprenda, es que me tiene realmente abrumado.
Por dios, no sabéis las horas y horas de resolución de errores, desesperos y cabreos que os váis evitar si ponéis en vuestra vida el modeo debug de la aplicación que estáis desarrollando. Cualquier entorno de desarrollo medianamente decente, un Eclipse, NetBeans, Visual Studio, Delphi 2006, Zend Studio para PHP, incorpora dicho valor.
No lo dejéis de lado. Vuestra eficiencia se verá directamente afectada si no aprovecháis el recurso del debug.
Nos cansamos de hablar de la mantenibilidad del código, de paquetizar, de reutilizar, de estándares de nomenclatura, de estilos definidos de programación, de separar entre el Modelo la Vista y el Controlador, de separar las aplicaciones en capas…
Pero no hay manera de que se nos meta en la cabeza que a la hora de maquetar una aplicación web típica, en la que existen millones de formularios de entrada (formularios que en una aplicación de escritorio se llevan a cabo arrastrando, soltando y colocando con el ratón elementos en el formulario), se haga siguiendo también un patrón, se aplique la reutilización y se defina una estructura que esté preparada para el cambio en caso de necesitar modificar el diseño por cambios en los requerimientos.
¿Consecuencias? Cada jsp, asp, aspx, php o html son de su padre y de su madre. Algunos resuelven problemas por javascript, otros con posts, otros con request, unos maquetan con tablas, otros con capas, otros <br> y  … Otros usando class, otros con style a pelo o asignando valores a las propiedades de los controles HTML.
¿Y con el tiempo que supone hacer todo eso… por qué no somos capaces de metérnos en la cabeza de la necesidad imperiosa de definir también una forma de trabajar con HTML?
“Pasar un despliegue a producción sin haberlo pasado primero a preproducción es como preparar una salsa y servirla a la mesa sin antes haber probado qué tal va de sal.” (Miguel Matas).
Con todo mi cariño a los amantes de hacer las cosas de cualquier manera.
