¿En qué momento hay que desplegar una nueva solución?

En software ocurre que no hay una misma respuesta para cada situación, para cada proyecto en el que cambia el número de personas involucradas en el equipo, la complejidad del mismo proyecto e incluso las tecnologías usadas. No obstante, lo que sí es cierto en todos los casos es que si se deja para el final el despliegue del sistema en un entorno lo más parecido o idéntico al de producción, nos encontraremos con muchos, muchísimos problemas.

Hay que desplegar en un entorno de producción lo más parecido al del cliente final tan pronto como se tenga alguna funcionalidad terminada pero completa, aunque sea simple.

Incluso si contamos con un entorno de integración fantástico y una gestión de la configuración para él magnífica, esto no nos garantizará que todo funcionará de maravilla en producción. Se podría escribir un libro entero sobre este tema, dependiendo de la naturaleza del proyecto e incluso del equipo, aunque me temo que casi nunca se tiene en cuenta el despliegue final hasta... ¡el final!, momento en el que nos podemos llevar muchas sorpresas.

Si no lo hacemos así, si no pensamos en el despliegue desde el principio, la brecha que nos encontraremos al final del proyecto cuando creemos que lo tenemos todo casi terminado, no hará más que agrandarse.

Un caso extremo de esto es cuando desarrollamos el proyecto en la misma máquina del cliente final..., llegando al caso de que fuera de él el proyecto requiere de una auténtica reingeniería (...) Esto, en software, es casi un pecado capital, al igual que probar contra bases de datos en producción o dispositivos que están en clientes finales. Vale sí, si hay que hacerlo, pues se hace cuando no haya más remedio, pero al menos tengamos en cuenta las consecuencias que puede tener.

Estas son las razones por las que opino que hay que publicar el proyecto en un entorno, llamémosle de pre-producción, lo antes posible.

Lo habitual es que un entorno de producción (= entorno que usará finalmente el cliente para usar nuestro proyecto) no tenga nada que ver con el entorno de desarrollo local que solemos usar. Eso es trivial y hasta frívolo decirlo, pero hasta que no sufrimos las consecuencias no nos damos cuenta de que muchas veces los SDKs que tienes en local y que no estarán en producción resulta que son imprescindibles, la configuración de una base de datos en producción puede que no sea la misma que la que tú usas en desarrollo (o incluso puede que sea hasta una versión diferente), la configuración del servidor o destino final puede que no tenga nada que ver con el entorno de los desarrolladores, sólo por poner unos ejemplos.

Es también corriente no detectar ciertos cuellos de botella porque en tu máquina local, al estar todo en el mismo equipo, todo va como la seda, con conexiones locales a la base de datos, si es que usas alguna, sin tener en cuenta la latencia que puede haber en ese punto si en producción la base de datos no está en local, está accesible remotamente o incluso el motor de base de datos es compartido, como suele ocurrir en diversos entornos.

Si se trata de una aplicación con una interfaz de usuario web, en local difícilmente vas a detectar problemas de rendimiento al cargar una simple página al no tener minimizados y concatenados los ficheros css y javascript. Eso sí puede ser un problema en un entorno real.

Hasta en entornos de alto nivel como .NET puede pasar que ciertas cosas funcionen a la perfección en modo debug y fallen de alguna manera inesperada en modo release, ¿sorprendido?

En local, en tu estación de trabajo, sueles tener a mano toda la información o trazas de cualquier cosa que ocurre en el sistema, ¿nos hemos asegurado de que en producción existe la misma trazabilidad? ¿Cuando algo falle, tendremos las herramientas necesarias para averiguar qué pasa en cada momento?

Hasta aquí comento muy por encima lo que podría ocurrir una vez el proyecto lo tienes desplegado, pero, ¿seremos capaces de desplegarlo todas las veces que haga falta? En otras palabras, debemos contar con una guía de despliegue que nos indique:

• El software base que debe estar preinstalado, versiones y su configuración (como Apache, IIS, node, SqlServer, MySql, Nginx, frameworks, Redis, etc.)
• Ubicación exacta de dónde se deben publicar todos los artefactos del proyecto. Esto es de vital importancia cuando esperamos publicar el proyecto en más de un cliente. Nada peor que tener algunas cosas por aquí y por allá y según la máquina de cada cliente, esto puede volver loco a quien le toque el mantenimiento (lo que equivale a una falta total de productividad)
• Pruebas finales que nos aseguren que todo está funcionado y en marcha. Estas no son pruebas unitarias o de integración, sino pruebas aunque sean manuales para garantizar que todo debería estar funcionando correctamente. Comúnmente este tipo de tests se llaman de validación y según qué proyectos los puede realizar el mismo cliente final para dar el ok definitivo al sistema.

Quizá suena un poco agorero todo lo anterior, pero es algo habitual que si no todo, gran parte de lo que he descrito te haya pasado en alguna ocasión.

La forma de evitarlo es ver el despliegue no como algo que se hace al final del proyecto, sino asumir la guía de despliegue como un artefacto más del mismo desde el primer momento. De esta forma, esta guía y sus actualizaciones a lo largo del desarrollo del proyecto nos permitirá avanzar en el mismo desde el primer momento de manera sólida, garantizando que la funcionalidad que tenemos hasta ahora, funciona tanto en los entornos de trabajo o de integración como en los entornos finales. Si tenemos suerte y el sistema hay que desplegarlo en veinte clientes nuevos, entonces ni tú o la persona encargada tendrá que pensar demasiado al estar todo documentado en esa guía de despliegue.

En mi opinión, la existencia de una guía de despliegue para cualquier proyecto es una síntoma de calidad.

¿A quién no le han pedido alguna vez que ponga en marcha un proyecto a partir del código fuente del mismo, y nada más? Terrorífico.