Continuous Delivery (II): Sus promesas

Como ya comentamos en Continuous Delivery: ¿Por qué te puede interesar? la meta que se pretende  alcanzar es la implantación de un mecanismo altamente automatizado que nos permita desplegar en los diferentes entornos (desarrollo, pruebas y producción) "presionando un botón".

En el anterior post describimos unas situaciones por las que nos podría interesar su implantación, ya que al no ser algo trivial, es aconsejable asegurarse de estar realmente interesado. Si reconoces con demasiada facilidad dichas situaciones y estás interesado en seguir adelante en este post se describen las ventajas que los autores "prometen":

• Disponer de un proceso de despliegue repetible, fiable y predecible. A demás de evitar las situaciones de las que hemos hablado anteriormente permitirá acortar el tiempo de ciclo de desarrollo acelerando la puesta a disposición de los usuarios nueva funcionalidad y la resolución de incidencias. Esto tiene mucho que ver con el principio de entregar con rapidez de Lean Software Development del que ya hablamos en ¿Restricciones en el demanda TI, de costes, de presupuesto? Tal vez te interese el pensamiento Lean.
  En cuanto a la característica "repetible", se puede llegar a pensar que no es tan difícil de conseguir siendo lo suficientemente metódicos pero lo cierto es que cuando los problemas y la fecha límite nos presionan es muy común saltarse los procedimientos y los manuales...de modo que después de 3 días de parches y cambios el sistema funciona...pero ¿somos realmente capaces de reproducirlo en el orden que corresponda y eliminando los pasos que no son necesarios?
• Fortalecer los equipos. El proceso de despliegue propuesto por CD tiene una característica importante y que igualmente enlaza con el pensamiento Lean: es un sistema Pull. Esto se traduce en que debe funcionar como un autoservicio, el desarrollador, tester o técnico de operaciones "tirará" de   la versión específica del sistema que necesita. El hecho de que se intente depurar un error (equipo desarrollo) sobre un código desfasado, se pruebe una versión (equipo de pruebas) que no corresponde o se pierdan dos horas desplegando un sistema (equipo de operaciones) con una documentación de puesta en producción desfasada conduce, generalmente, a problemas entre los diferentes equipos que participan en todo el proceso.
• Reducir errores. Desde el momento de captura de requisitos hasta la puesta en producción existen un gran numero de posibilidades de introducción de errores. CD se centra en la reducción de los errores producidos específicamente en producción como consecuencia de una gestión de la configuración deficiente: una versión específica de nuestro sistemas implican un código fuente determinado, asociado con una versión específica de la base de datos, URLs concretas para el acceso a servicios Web, etc. Controlando todos y cada uno de estos elementos bajo una gestión de la configuración adecuada se reducirán considerablemente (ojo no digo "se eliminarán por completo"... desconfía de quien lo prometa) los problemas "inesperados" en producción. 
• Minimizar el estrés. Si has participado en un proyecto software tendrás muy presente que según se acerca la fecha de la entrega el estrés aumenta de forma considerable (posiblemente las horas extras también). Es el momento de la adrenalina..., de los héroes locales... y de saltarse los protocolos (con los correspondientes visados de la jerarquía superior, por supuesto) y no es de extrañar que en operaciones llegue la orden de abrir la base de datos e introducir manualmente los valores de configuración que algún desarrollador va indicando sobre la marcha...porque el sistema ha de arrancar sí o sí... En desarrollo llegan "visados" similares siendo necesario tocar código que ha de subir a producción en minutos...por lo que, obviamente, se saltan todos los procedimientos de calidad establecidos.
  Este tipo de órdenes pueden estar justificadas y seguirán realizándose si el coste de no ejecutarlas lo justifica...vivimos en el mundo real...¿alguien piensa que el CTO de una tienda Online no firmaría visados para arreglar un problema en la plataforma de pago (único punto de entrada de ingresos)? pero ¿tendríamos el mismo estrés si nuestro despliegue se hubiese preparado desde el Día 1 para que pudiera realizarse "presionando un botón"? Con toda probabilidad los datos que el técnico de sistemas se ve obligado a introducir "a ciegas" formarían parte de un script listo y preparado para su ejecución (de hecho no sería la primera vez que se lanzara).
• La práctica lleva a la perfección. No es cuestión de definir la mejor y más sofisticada técnica para esta  u otra tecnología (para eso ya están, de nuevo, los héroes locales)... es más simple que eso puesto que el efecto de desplegar continuamente el sistema acabará creando, por si solo, un procedimiento detallado (¡y probado!). Si esto lo hacemos desde el primer día del proyecto cuando tengamos que desplegar el día D habremos verificado dicho procedimiento decenas de veces.

Ahora bien, para poder automatizar el proceso de despliegue necesitarás dos pilares básicos, por lo que si no dispones de ellos es imprescindible que inicies tu camino aquí:

Gestión de la Configuración
En muchas ocasiones se confunde este término con el "control de código fuente" pero en realidad la gestión de la configuración va más allá, en [1] se define como el proceso por el cual todos los artefactos relevantes para nuestro proyecto y sus relaciones son almacenados, recuperados, identificados inequívocamente y modificados.

El enfoque de CD es mantener bajo la gestión de la configuración absolutamente todos los elementos que serán necesarios para el despliegue, esto implica por supuesto al código fuente pero también a la configuración de la base de datos, la configuración mínima que requieren las aplicaciones para funcionar así como la diferente configuración de entorno (sistemas operativos, servidores de aplicaciones, etc.).

Una buena estrategia de Gestión de la Configuración es básica para cualquier proyecto software, por lo que si no dispones de ella, es recomendable que estés o no interesado en CD lo incluyas en tu lista de "temas urgentes" a realizar.

Integración Continua
Para poder automatizar los despliegues es necesario asegurar que en todo momento disponemos de una versión estable de nuestro código, asegurándonos de que compila y pasa un conjunto de pruebas que garantizan (dentro de lo razonable) su correcto funcionamiento. La mejor forma de conseguir esto es mediante la práctica de Integración Continua. Al igual que ocurre con la Gestión de la Configuración muchas veces interpretada como sinónimo de "control de código fuente" la Integración Continua se suele asociar con la compilación remota, aunque en realidad tiene mayores implicaciones que disponer de dicha infraestructura como ya comentamos en "Practicando" la Integración Continua (IC).


Referencias
[1] Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation, Jez Humble y David Farley