Prerrequisitos para una Implementación Exitosa de la Entrega Continua

La entrega continua está ganando rápidamente la atención de las organizaciones, ya que ayuda a satisfacer la demanda creciente para entregar software de manera ágil. Con su énfasis en mantener el software en un estado “listo para despliegue” en todo momento, es una evolución natural de las prácticas de integración continua y desarrollo ágil de software. Sin embargo, los retos culturales y operacionales para lograrlo son mucho más grandes que dichas prácticas. Para la mayoría de las organizaciones, la entrega continua requiere la adaptación y extensión de los procesos existentes de liberación de software. Los roles, relaciones y responsabilidades de la gente en toda la organización también pueden ser impactados; por otra parte, las herramientas utilizadas para entregar, actualizar y mantener el software deben apoyar la automatización y colaboración en forma apropiada, con el propósito de minimizar demoras en el despliegue de nuevos servicios y proporcionar ciclos de retroalimentación rápida en toda la empresa.

Las organizaciones que están buscando hacer la transición a la entrega continua deben considerar los siguientes siete prerrequisitos. Son pasos prácticos que les permitirán ejecutar en forma exitosa los cambios culturales y operacionales dentro del marco legal y funcional en el cual operan.

Los equipos de desarrollo, QA y operaciones deben tener metas compartidas y comunicarse

Mientras que la integración continua limita el alcance del equipo de desarrollo, la entrega continua incluye las fases de prueba del equipo de aseguramiento de calidad (QA) y los despliegues a producción manejados por el equipo de operaciones. Esto es un cambio de paradigma importante, y para tener éxito evolucionando una práctica de integración continua a entrega continua, es crítico que los equipos de desarrollo, QA y operaciones tengan un modelo de gobernanza (governance) compartido. La colaboración y la comunicación son componentes vitales del desarrollo exitoso de software hoy en día, y en un ambiente de entrega continua tienen que tomar el centro del escenario.

La integración continua debe funcionar antes de moverse a la entrega continua

La entrega continua es una extensión de la integración continua, su prerrequisito es tener la integración continua implementada y funcionando, incluyendo control de versiones, y construcción automatizada (automated builds) con pruebas unitarias y pruebas automatizadas.

Automatiza y haz versiones de todo

La entrega continua involucra la repetición continua de muchas tareas tales como hacer builds, desplegar aplicaciones y configuraciones, restaurar ambientes y bases de datos. Todas estas tareas se deben automatizar con herramientas y scripts, y todo se debe mantener bajo control de versiones para poder auditarlo y reproducirlo.

Compartir las herramientas y procedimientos entre equipos es crítico

La entrega continua apunta a validar los procedimientos de implementación y automatización utilizados en el ambiente de producción; para hacerlo exitosamente, estos procedimientos y automatizaciones deben ser utilizados tan temprano como sea posible de forma tal que, sean ampliamente probados cuando se usen para implementar software a el ambiente de producción. En la mayoría de los casos, las mismas herramientas pueden utilizarse en todos los ambientes (pruebas, preproducción y producción).

Los scripts de automatización deben manejarse en repositorios compartidos de código fuente de tal forma que cada equipo —desarrollo, QA y operaciones— pueda mejorar las herramientas y los procedimientos. Mecanismos como pull-requests pueden ayudar al gobierno de estos scripts y herramientas.

La aplicación tiene que ser amigable en su despliegue para hacer que las implementaciones no generen eventos disruptivos

Las aplicaciones deben simplificar sus procedimientos de instalación y marcha atrás (rollback) para minimizar conflictos. Un paso importante para lograrlo es reducir el número de componentes y de parámetros de configuración. La facilidad de dar marcha atrás, brinda la posibilidad de que en caso de que haya algún problema con una instalación se pueda rápidamente deshacer y regresar el sistema a su estado anterior. La capacidad de activar capacidades de forma independiente (feature toggle) permite desacoplar la instalación de binarios de la activación de capacidades, de esta manera si hay un problema al activar una capacidad, simplemente se desactiva en lugar de tener que reinstalar los binarios anteriores. Una marcha atrás entonces puede ser simplemente la desactivación de la misma , gracias a una tecla de conmutación.

Se debe poner especial atención a cualquier cambio en el esquema de las bases de datos, ya que se pueden volver mucho más complejas las implementaciones y los retrocesos. El patrón de diseño sin esquema de las bases de datos NoSQL trae mucha flexibilidad, pasando la responsabilidad del esquema desde la base de datos, al código. Este concepto también puede ser aplicado a bases de datos relacionales.

La infraestructura debe apuntalar el proyecto para potenciar a la gente y equipos

Las infraestructuras deben proporcionar todo el equipamiento (GUIs, APIs y SDKs) y documentación requeridos para empoderar al equipo de desarrollo y QA, y hacerlos autónomos en su trabajo. Estas tareas incluyen:

• Poder implementar la versión de su elección de la aplicación.
• Gestionar los parámetros de configuración (ver, modificar, exportar, importar).
• Gestionar bases de datos (crear snapshots y restaurar a partir de estos).
• Dar acceso a las bitácoras (logs) de la aplicación.

Las plataformas de nube pública, principalmente en modelos de Plataforma como Servicio (PaaS), son ejemplos de plataformas amigables con los proyectos.

Las versiones de aplicaciones deben estar listas para ser enviadas a producción

Una de las metas más importantes de la entrega continua es permitir que el dueño de producto pueda desplegar en producción cualquier versión de la aplicación que pase exitosamente el conducto (pipeline) de entrega continua, en lugar de solo poder liberar las versiones mayores que resultan al final de una iteración.

Alcanzar este objetivo requiere cambios importantes en la forma en que son diseñadas las aplicaciones, por ejemplo: las características que aún no han sido validadas por el equipo de QA se deben poder ocultar a los usuarios finales sin que la base de código se modifique. Dichas características deben estar en ramas (branches) de código distintas a la rama maestra, e incorporarse a la rama maestra hasta que hayan sido validadas por QA y aceptadas para su uso en producción. Otra posibilidad es usar feature toggling que consiste en poder activar o desactivar una funcionalidad desde alguna consola de administración.

Las herramientas de construcción deben evolucionar del concepto de versiones semánticas (SemVer) hacia un flujo continuo de versiones. En el caso de subversion, es sencillo ya que automáticamente provee un número de versión ordenado. En el caso de Git, dado que su árbol de versiones no es lineal, es un poco más complicado y requiere acuerdos en cuanto a cómo se va a organizar el árbol de versiones y la nomenclatura que se le dará.

Conclusión

La entrega continua no solo se trata de un conjunto de herramientas. También debe tomar en cuenta a las personas y la cultura organizacional. La tecnología, la gente y el proceso necesitan estar alineados para hacer que la entrega continua sea exitosa; y un enfoque colaborativo es fundamental para su éxito. Implementar estas mejores prácticas puede permitir a las organizaciones cosechar las recompensas de un enfoque automatizado más fluido al desarrollo de software, y uno que también proporciona agilidad de negocios.