Día 1: El mejor momento para el despliegue

Las puestas en producción suelen ser complicadas, incluso si hemos superado los innumerables problemas durante el desarrollo del producto, hemos corregido a tiempo los errores detectados en las pruebas y disponemos de una versión estable para el despliegue, en ocasiones nos encontramos superando la fecha de entrega en varias semanas por la necesidad de "afinar el sistema" al entorno de producción.

Puede parecer demasiado prematuro (e irreal) pero lo cierto es que no encontraremos en la vida de un proyecto mejor momento para su puesta en producción que su primer día de vida. Bien, tal vez tengamos que acotar lo que entendemos por "primer día" puesto que desde el momento de la concepción del sistema hasta que se escribe la primera línea de código pueden pasar varios días, tal vez semanas o incluso meses...

Durante las puestas en producción nos encontramos con una serie de problemas difíciles de predecir y reproducir, por lo que suele ser complicado aprender y replicarlo en el siguiente proyecto: debemos desplegar por sorpresa en servidores de 64 bits, la versión del Componente X de producción no coincide exactamente con la de Preproducción/Desarrollo, no alcanzamos desde los servidores de producción determinado Servicio Web, no está habilitada la IP de los nuevos servidores para el envío de correos, no se ejecutó el script con los permisos sobre determinados objetos de la base de datos... en resumen, la casuística tiende a infinito...

Cuanto más se retrasa la puesta en producción de nuestro sistema más funcionalidad incorpora, más lógica de negocio, mayor necesidad de configuración y de integración con otros sistemas... en definitiva, más riesgo a manejar. De ahí la afirmación que el primer día es el mejor momento para el despliegue.

Dependiendo del entorno, tecnología u organización el "primer día" puede traducirse como "la primera semana" o "el primer mes" pero lo cierto es que siempre habrá un único momento del proyecto en el que el despliegue es sencillo, pasado ese momento la complejidad va en aumento.

En nuestros proyectos intentamos evitar este problema cambiando el orden natural del despliegue, en lugar de desplegar al finalizar proyecto o en la primera iteración entregable, desplegamos un ¡Hola Mundo! tan pronto como nos es posible. Con esto no me refiero a las 3 líneas de código que escribimos al iniciarnos en un nuevo lenguaje de programación. En realidad nuestro ¡Hola Mundo! debe hacer algo más: 

• "Nos saluda" desde el Log. Lo cual no es decir poco; esto implica que hemos definido la estrategia de tratamiento de Logs, tenemos acceso de escritura donde quiera que se registre y el equipo de desarrollo dispone de accesos de lectura para verificar que el "recién nacido" respira.
• Establece conexión con los orígenes de datos que utilizará (SGBD, WebServices, ...) y nos informa positiva o negativamente a través del Log.
• Disponemos de, al menos, una prueba unitaria y una prueba de sistema. En realidad buscamos asegurarnos que existen los proyectos de pruebas asociados y se lanzan junto con la compilación. Las pruebas en este momento no nos preocupan demasiado, con un AssertTrue(true) tendremos el efecto deseado: 100% de las pruebas ejecutadas y funcionando.
• Nuestra máquina de Build dispone de una definición de compilación que obtiene nuestro (escaso) código, ejecuta las pruebas (obviamente pasan) y nos proporciona la carpeta de despliegue.

Durante nuestro "primer día de proyecto" hacemos las tareas que solíamos realizar en los últimos días: solicitar un código de identificación para nuestro sistema en producción, darlo de alta en la CMDB corporativa, escribir los manuales de instalación... La ventaja es que a partir de ese momento (la primera semana del proyecto) somos capaces de asegurar que nuestro sistema se ejecuta correctamente en el entorno de producción. Vale, al usuario le aporta poco o nada, de hecho se trata de una producción oculta...pero a nosotros nos aporta una información de gran valor.

Obviamente para desplegar un ¡Hola Mundo! no es necesario automatizar las pruebas ni utilizar máquinas de compilación remota. En nuestro caso lo hacemos así porque es la configuración por defecto de nuestros proyectos y garantiza que cualquier incremento de código no rompa la build ni deje test sin funcionar, obviamente se deben desarrollar más allá del AssertTrue(true). Lo que realmente nos interesa es verificar que el nuevo sistema "se levanta" correctamente en producción, conecta con los sistemas con los que se  deberá integrar y nos informa positivamente al respecto. No hacemos nada que no haríamos unos meses después (no desperdiciamos tiempo ni recursos) y anticipándonos convertimos en problemas reales los riesgos futuros y al despejarlos en un instante tan prematuro el tiempo corre a nuestro favor.

Día 2 del proyecto: el mejor momento para desplegar la versión 0.2 

Bueno, si lo dicho anteriormente puede llegar a encajar (al menos en un porcentaje aceptable de proyectos)  ¿Por qué no repetirlo al día siguiente? Y por "día siguiente" queremos decir tan pronto como sea posible... 

La idea es que si ya dispongo de una versión operativa en producción, no debo esperar hasta la entrega final para volver a realizar el despliegue. Si todos los días despliego mi nueva funcionalidad, todos los días validaré que el procedimiento de despliegue funciona y el "día D" pasará de ser "los 4 días D" a un despliegue rutinario... nosotros nos estamos aproximando a esta idea a partir del enfoque explicado por Jez Humble y David Farley en Continuous Devivery (CD).

Ahora bien, si para desplegar nuestro ¡Hola Mundo! no teníamos muchas restricciones, en esta nueva fase sí que necesitaremos un buen control de código fuente y una práctica "real" de integración continua. El enfoque que sigue CD es automatizar al máximo el proceso de despliegue (el objetivo final es que la única intervención humana sea pulsar el botón) por lo que igualmente necesitaremos  máquinas de compilación remotas.

El esfuerzo de implantar Continuous Delivery (CD) va mucho más allá que la buena práctica de desplegar y validar nuestro sistema tan pronto como sea posible explicada gráficamente con nuestro ¡Hola Mundo! El objetivo que perseguimos es que diariamente se valide nuestro proceso de puesta en producción, lo cual no implica que todo los días deba liberar una versión, sino que disponemos de un procedimiento que funciona y nos ofrece las garantías necesarias para poder asumir un despliegue inmediato si tuviera la necesidad de hacerlo de urgencia.

Esto son palabras mayores y el esfuerzo no es trivial, actualmente estimo que llevaremos andado una buena parte del camino...en próximos post iremos explicando en más detalle los entresijos de CD y cómo, poco a poco, lo vamos afrontando nosotros.