martes, 26 de febrero de 2013

Continuous Delivery: ¿Por qué te puede interesar?

Empecemos definiendo qué es Continuous Delivery (CD): Consiste básicamente en la implantación de un proceso repetible y confiable para la liberación de software evitando, en la medida de lo posible, la intervención humana. Los autores de Continuous Delivery [1] aconsejan que la única intervención por nuestra parte para la liberación de una nueva versión sea la de pulsar el botón de despliegue para lo que será necesario disponer en todo momento de una versión de software estable listo para la entrega.


Este objetivo es realmente ambicioso y como te puedes imaginar su puesta en marcha requiere un esfuerzo importante por lo que deberías hacerte algunas preguntas antes de planteártelo. Para ayudarte en esta  decisión te recomiendo que leas las siguientes situaciones, si te resultan demasiado familiares te puede compensar hacerte con el libro y profundizar en sus ideas.

Situaciones derivadas de un proceso de despliegue manual

En muchas organizaciones la gestión de la configuración del entorno de producción se lleva a cabo directamente por equipos de operaciones. De esta forma cuando se requiere cambiar la cadena de conexión a una base de datos, el acceso con certificado o el uso del canal seguro para una aplicación se lleva a cabo manualmente en los servidores de producción. Este hecho puede provocar las siguientes situaciones:
  • Para desplegar un sistema es necesaria la edición de elaborados manuales de instalación que describen secuencialmente los pasos que deberá realizar el equipo de operaciones.
  • El proceso de despliegue finalmente no sigue el plan establecido, en diferentes momentos es necesario  improvisar y no se sigue el manual. 
  • Se hace necesario establecer una conexión telefónica permanente entre desarrollo y operaciones durante el proceso de despliegue. En ocasiones se requiere desplazar algún miembro del equipo de desarrollo a las instalaciones del equipo de operaciones.
  • Se hace necesaria la realización de pruebas manuales en entorno de producción para asegurarnos que la aplicación se ejecuta correctamente y que interacciona de forma adecuada con sistemas externos.
  • Falla un despliegue en producción aun después de haberse desplegado perfectamente en entorno de pre-producción.
  • Los nodos de un cluster tienen diferentes versiones de sistemas operativos, componentes de terceros o parches, lo que deriva en que la aplicación se comporta de diferente forma dependiendo del nodo que atiende la petición.
  • El equipo de operaciones requiere más tiempo del estimado inicialmente para preparar el entorno requerido por una versión específica de nuestro software.
  • No es posible retroceder a una versión anterior de un sistema después de un determinado pase que implica bases de datos, servidores de aplicaciones, parches de sistemas operativos, etc.
  • La configuración de los sistemas se llevan a cabo manualmente a través de herramientas de administración proporcionadas por los propios Sistemas Operativos, SGBD, servidores de aplicaciones, etc.
Situaciones derivadas de desplegar en entorno real justo cuando finalizamos el desarrollo

Esto suele ser muy común y no deja de ser un problema puesto que existe un enorme número de riesgos asociados a la arquitectura técnica (¡pueden exigir tocar código!) que se descubrirán cuando el equipo de desarrollo da por finalizado su trabajo. Obviamente cuanto más tardemos en "conocer" el entorno de producción mayores y más peligrosos se harán estos riesgos, de esto ya hablamos en un post anterior por lo que argumentábamos que el día 1 era el mejor momento para el despliegue. A continuación se describen alguna de las situaciones que nos podemos encontrar
  • La primera vez que el equipo de operaciones se "enfrenta" al nuevo software es el día D. Generalmente las organizaciones siguen una política común que minimiza este impacto pero siempre existe un motivo para que en desarrollo nos veamos obligados a realizar un proyecto que se sale de la norma provocando que el equipo de operaciones no se encuentre tan "cómodo" con el despliegue. 
  • El entorno de pre-producción (lo más parecido que tendremos a producción) no está disponible hasta que nos encontramos demasiado cerca de la fecha límite.
  • Derivado de lo anterior, las pruebas se han realizado sobre el entorno de desarrollo y la pre-producción no se comporta igual ante determinadas funcionalidades.
  • Hay poca, o ninguna, colaboración entre el equipo de desarrollo y el de operaciones. 
  • En proyectos de larga duración, en los que están implicados equipos de la propia organización y desarrollos subcontratados con proveedores externos es habitual que el despliegue sea el momento de revisar los documentos contractuales. Si el contrato se redactó a nuestro favor y el proveedor debe hacerse cargo de, por ejemplo, un cambio de plataforma, estamos de media enhorabuena... porque seguramente esto ocurra, de nuevo, pisando la fecha límite.
¿Te suena alguna de las anteriores situaciones? Aunque la lista está recopilada de Continuous Delivery [1] personalmente he de reconocer que las he sufrido un su gran mayoría y que podría ampliarla fácilmente.

Reducir estas situaciones es, desde mi punto de vista, suficiente motivo para afrontar el esfuerzo que requiere la implantación de CD, claro que el grado de automatización sugerida puede y debe variar dependiendo de la naturaleza de los sistemas que estemos desarrollando.

Existen dos motivos que a nosotros nos condujeron a CD:
  1. Nos resultaba demasiado familiar las situaciones descritas anteriormente. 
  2. Desde una perspectiva ágil cuanto menor sea la duración de la iteración mayor necesidad tendrás de automatización en el proceso de despliegue. En nuestro caso, el hecho de utilizar un tablero Kanban en el equipo de desarrollo nos ha generado la necesidad de aumentar la sofisticación del proceso de despliegue debido al flujo continuo promovido por dicho método
En próximos post resumiré las bases mínimas sobre las que se apoya CD, los beneficios esperados así como nuestras experiencias al implementarlo.


Referencias
[1] Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation, Jez Humble y David Farley
[2] http://www.continuousdelivery.com/


No hay comentarios:

Publicar un comentario