Despliegue continuo

El despliegue continuo es un proceso que verifica la estabilidad y correctitud de

cambios introducidos en el código de un software mediante pruebas automatizadas,
permitiendo su despliegue inmediato y autónomo al entorno de producción. Esto significa
que cualquier cambio en el codigo subido al repositorio que se utiliza para el control de
versiones sera testeado, compilado y desplegado de forma automática.
Si bien es confundido usualmente con el concepto de entrega continúa, la diferencia
entre ambas es el nivel de automatización que se tiene en estos procesos. En el caso de la
entrega continúa, el paso final donde se despliega el producto debe ser realizado
manualmente, mientras que en el despliegue continuo se realiza de forma automática
cuando el codigo pasa las pruebas necesarias.

La ventaja principal que ofrece es la posibilidad de adaptarse continuamente a los

cambios del mercado, permitiendo a los equipos de desarrollo desplegar y validar de forma
rápida nuevas ideas. Es decir, permite que el equipo de desarrollo reaccione casi en tiempo
real a la retroalimentación de los usuarios.
 Si bien integrar el proceso de despliegue continuo dentro de una organización puede
resultar tentador, hay ciertos pre-requisitos que se deberán tener en cuenta para minimizar
la posibilidad de errores, considerando que integrar el despliegue continuo para un producto
de software o incluso una organización no es barato.
El primer punto a considerar es que las áreas encargadas de la direccion tienen que estar
convencidas y predispuestas a realizar el cambio, si no se adopta al nivel mas alto de la
organización, sera mucho mas dificil integrarlo en el resto de la misma.
En segundo lugar, se deberia contar con un producto de software desarrollado de forma de
respetar el bajo acoplamiento y la alta cohesion, dado que esto permite que los cambios
necesarios para resolver ya sea un bug o el desarrollo de un nuevo requerimiento sean lo
mas atomicos posibles, minimizando el riesgo de introducir errores.
En tercer lugar, el codigo deberia tener desarrolladas pruebas automatizables, tanto
unitarias como a nivel subsistema, para un porcentaje lo mas cercano al 100% de la base
de codigo.

Estrategias (No exhaustivo):

blue/green deployments: Estrategia que utiliza dos conjuntos de servidores como entornos
de producción semi-espejados, además de un proxy reverso, enrutador o balanceador de
carga configurable para dirigir el trafico entrante al conjunto de servidores requerido. En un
momento dado, un conjunto de servidores (Azul) tiene la ultima versión estable y es la que
recibe el trafico, mientras que el otro (Verde) es donde el proceso de CD realizara el
despliegue, es decir, el router esta dirigiendo el trafico entrante al conjunto Azul. Una vez
desplegada la ultima versión y comprobado su funcionamiento se invierte la configuración
del router para que dirija el trafico al conjunto azul. Es decir, se va intercambiando
iterativamente el conjunto de servidores que reciben el trafico a medida que se despliegan
nuevas versiones y se verifica su estabilidad.

Esto permite, por un lado maximizar la eficiencia de cada despliegue de forma de reducir al
minimo el downtime que tiene el sistema permitiendo además un rollback rápido de los
cambios, puesto que en caso de un error o problema en la ultima versión desplegada se
puede volver rápidamente a la ultima versión estable con sólo modificar la configuración del
router o balanceador.
Canary deployment: Similar a la estrategia anterior, en este caso en lugar de desplegar un
nuevo conjunto de cambios a uno de los dos conjuntos o clusters semi espejados, ve la
infraestructura como un sólo conjunto de servidores, pero realiza el despliegue a una
fracción de ellos, configurados para no recibir trafico. En función de la estabilidad de esta
versión desplegada, se comienza a redirigir una porción mínima del trafico a estos
servidores, numero que se incrementa a medida que se gana confianza sobra la estabilidad
y rendimiento de la nueva versión, al mismo tiempo que se va desplegando la misma en
mas servidores para soportar el creciente numero de usuarios. Algunas empresas deciden
los usuarios que accederan a la ultima versión de manera aleatoria, mientras que otras,
como Facebook redirigen a sus empleados a la versión mas actual desplegada. Otra
estrategia usada si la empresa tiene sus servidores distribuidos geográficamente es la de
desplegar la nueva versión a una zona o region especifica y verificar allí su funcionamiento.
Permite no sólo testear incrementalmente el rendimiento y estabilidad de nuestra nueva
versión, sino que además permite un rollback rápido, seguro y relativamente sencillo en
caso de encontrar fallas. Por otro lado, al incrementar lentamente la carga en los servidores
con la versión nueva, se puede monitorear y realizar captura de métricas para verificar
como los cambios impactan en el sistema.
Webgrafia
https://www.atlassian.com/continuous-delivery/continuous-deployment
https://research.fb.com/wp-content/uploads/2017/01/paper_icse-savor-2016.pdf
https://martinfowler.com/bliki/CanaryRelease.html
https://martinfowler.com/bliki/BlueGreenDeployment.html
Bibliografia
Continuous Integration Delivery and Deployment - Sander Rossel - 2017 Packt Publishing -
ISBN 978-1-78728-661-0