Conceptos básicos sobre la canalización de entrega continua

Por tópica que parezca, la expresión "errar es humano" es muy cierta. Las publicaciones manuales son procesos delicados y, cuando llega el momento, los equipos contienen la respiración. "Predecible" implica que las publicaciones son deterministas cuando se realizan a través de canalizaciones de entrega continua. Las canalizaciones son infraestructuras programables, por lo que los equipos pueden esperar siempre el comportamiento deseado. Por supuesto, ningún software está libre de errores y pueden ocurrir accidentes. Sin embargo, las canalizaciones son mucho mejores que los procesos de publicación manual propensos a errores, ya que, a diferencia de los seres humanos, las canalizaciones no fallan por estar sometidas a la presión del reloj.

Los canales cuentan con puertas al software que hacen o evitan automáticamente que pasen los artefactos sometidos a control de versiones. Si no se reconoce el protocolo de versiones, las puertas al software permanecen cerradas y el canal anula la operación. Se generan alertas y se envían notificaciones a una lista de distribución con los miembros del equipo que podrían haber roto el canal.

Así es como funciona una canalización de CD: una confirmación (o un pequeño lote gradual de confirmaciones) llega a la producción cada vez que el canal se ejecuta satisfactoriamente. Finalmente, los equipos lanzan funciones y productos de una forma segura y controlable.

La arquitectura del producto que fluye por el canal es un factor clave que determina la anatomía del canal de entrega continua. La arquitectura de un producto muy vinculado genera un complejo patrón de canal gráfico en el que se entrelazan diversos canales antes de llegar a la producción.

La arquitectura del producto también influye en las diferentes fases del canal y en los artefactos producidos en cada fase. Veamos las cuatro fases habituales de la entrega continua:

1. Fase de Componente
2. Fase de subsistema
3. Fase del sistema
4. Fase de Producción

Aunque cuentes con más o menos de cuatro fases en tu organización, los siguientes conceptos siguen siendo aplicables a tu caso.

Se suele tener la idea equivocada de que estas fases tienen manifestaciones físicas en la canalización. No tiene por qué ser así. Son fases lógicas y pueden aplicarse a hitos ambientales como las pruebas, el entorno de ensayo y la producción. Por ejemplo, los componentes y los subsistemas se podrían crear, probar e implementar durante las pruebas. Los sistemas o subsistemas se podrían montar, probar e implementar en el entorno de ensayo. Los sistemas o subsistemas se podrían promover hacia la producción como parte de la fase de producción.

El coste de los defectos es bajo cuando estos se detectan en las pruebas; medio, si se detectan en el entorno de ensayo, y alto durante la producción. "Shift Left" hace referencia al acto de mover las validaciones a una fase anterior de la canalización. El umbral que hay entre las pruebas y el entorno de ensayo cuenta con muchas más técnicas defensivas incorporadas hoy en día. Por tanto, el entorno de ensayo ya no tiene por qué parecer la escena de un crimen.

Tradicionalmente, InfoSec empezaba su trabajo al final del ciclo de vida de desarrollo de software y rechazaba las publicaciones que podían suponer amenazas para la ciberseguridad de la empresa. Aunque sus intenciones eran buenas, provocaban frustraciones y retrasos. "DevSecOps" defiende que la seguridad se debe incorporar en productos desde la fase de diseño, en lugar de enviar un producto acabado (posiblemente no seguro) para su evaluación.

Veamos con más detalle cómo tratar "Shift Left" y "DevSecOps" en el flujo de trabajo de entrega continua. En estas próximas secciones, veremos cada fase detalladamente.

La canalización primero compila componentes: las unidades mínimas para pruebas y distribución del producto. Por ejemplo, una biblioteca compilada por la canalización se puede denominar "componente". Un componente puede certificarse, entre otras cosas, mediante revisiones de código, pruebas unitarias y analizadores de código estático.

Las revisiones del código son importantes para que los equipos tengan una concepción común sobre las funciones, pruebas e infraestructura necesarias para poner en marcha el producto. A veces, una segunda opinión puede hacer maravillas. Con los años, puede que nos volvamos inmunes al código de baja calidad y creamos que no lo sea. Las nuevas perspectivas pueden llevarnos a revisar aquellos puntos débiles y a refactorizar a fondo si fuese necesario.

Las pruebas unitarias son casi siempre el primer conjunto de pruebas de software que ejecutamos en nuestro código. No tocan la base de datos ni la red. La cobertura de código es el porcentaje de código que han tocado las pruebas unitarias. Hay muchas formas de medir la cobertura, como la cobertura de línea, de clase, de método, etc.

Aunque contar con una buena cobertura de código para facilitar la refactorización es una idea excelente, resulta perjudicial exigir objetivos de gran cobertura. Al contrario de lo que podría parecer, algunos equipos con una alta cobertura de código experimentan más interrupciones de producción que los equipos con una cobertura más baja. Asimismo, hay que tener en cuenta que es sencillo jugar con los números de cobertura. Si los desarrolladores se encuentran bajo mucha presión, sobre todo durante las revisiones de rendimiento, pueden recurrir a prácticas desleales para aumentar la cobertura de código. Pero ¡no voy a entrar en detalles!

El análisis de código estático detecta problemas en el código sin ejecutarlo. Es una forma económica de detectar incidencias. Al igual que las pruebas unitarias, estas pruebas se ejecutan en el código fuente y tienen un tiempo de ejecución corto. Los analizadores estáticos detectan posibles fugas de memoria, junto con indicadores de calidad del código como la complejidad ciclomática y la duplicación de código. En esta etapa, las pruebas de seguridad de análisis estático (SAST) son una forma demostrada de detectar vulnerabilidades de seguridad.

Define las métricas que controlan las puertas al software e influye en la promoción de código desde la fase de componente hasta la fase de subsistema.

Los componentes poco vinculados conforman los subsistemas: las unidades implementables y ejecutables más pequeñas. Por ejemplo, un servidor es un subsistema. Un microservicio ejecutado en un contenedor es también un ejemplo de subsistema. Al contrario que los componentes, los subsistemas se pueden sacar y validar según casos reales de clientes.

Al igual que una interfaz de usuario de Node.js y una capa de API de Java son subsistemas, las bases de datos también son subsistemas. En algunas organizaciones, los sistemas de gestión de bases de datos relacionales (RDBMS) se gestionan de forma manual, aunque haya surgido una nueva generación de herramientas que automatice la gestión de cambios en las bases de datos y lleve a cabo satisfactoriamente la entrega continua de bases de datos. Los canales de CD con bases de datos NoSQL son más fáciles de implementar que los RDBMS.

Se pueden implementar y certificar subsistemas mediante pruebas funcionales, de rendimiento y de seguridad. Vamos a ver cómo cada tipo de prueba valida el producto.

Las pruebas funcionales incluyen todos los casos reales de clientes que implican la internacionalización (I18N), localización (L10N), calidad de datos, accesibilidad, situaciones negativas, etc. Estas pruebas garantizan que el producto funcione según las expectativas del cliente, respete la inclusión y sea adecuado para el mercado al que se dirige.

Determina tus referencias de rendimiento con los propietarios del producto. Integra tus pruebas de rendimiento con el canal, y usa las referencias de aprobación o fallo de las canalizaciones. Se suele creer que las pruebas de rendimiento no se deben integrar con las canalizaciones de entrega continua; sin embargo, esto desmonta el paradigma continuo.

En los últimos tiempos, las principales organizaciones han sufrido ataques y las amenazas a la ciberseguridad son más intensas que nunca. Debemos abrocharnos el cinturón y asegurarnos de que no existen vulnerabilidades de seguridad en nuestros productos, ya sea en el código que escribimos o en las bibliotecas de terceros que importamos en nuestro código. De hecho, se han descubierto infracciones importantes en software de código abierto (OSS) y debemos utilizar herramientas y técnicas que marquen estos errores y hagan que la canalización los cancele. Las pruebas de seguridad de análisis dinámico (DAST) son una forma demostrada de detectar vulnerabilidades de seguridad.

La siguiente ilustración plasma el workflow tratado en las fases de componente y subsistema. Ejecuta pasos independientes en paralelo para optimizar el tiempo total de ejecución del canal y obtener feedback rápidamente.

Cuando los subsistemas cumplen expectativas funcionales, de rendimiento y de seguridad, se podría enseñar a la canalización a ensamblar un sistema a partir de subsistemas poco vinculados cuando todo el sistema debe publicarse como una unidad. Esto significa que el equipo más rápido puede ir a la velocidad del más lento. ¿Recuerdas el dicho "Una cadena es tan fuerte como su eslabón más débil"?

Desaconsejamos este antipatrón, en el que varios subsistemas se reúnen en un sistema que se publica como una unidad. Para funcionar, este antipatrón une todos los subsistemas. Si inviertes en artefactos que se pueden implementar de forma independiente, podrás evitar este antipatrón.

Si hay que validar sistemas como una unidad, se pueden certificar mediante pruebas de integración, rendimiento y seguridad. A diferencia de la fase de subsistema, no utilices objetos ficticios ni código auxiliar durante las pruebas en esta fase. Además, es importante que te centres en probar interfaces y redes.

La siguiente ilustración resume el workflow en la fase de sistema, en caso de que tengas que montar los subsistemas mediante la composición. Aunque puedas implementar tus subsistemas en la producción, la siguiente ilustración ayuda a establecer las puertas al software necesarias al promover código desde esta fase hasta la siguiente.

La canalización puede archivar automáticamente solicitudes de cambio (CR, por sus siglas en inglés) para dejar un registro de auditoría. La mayoría de las organizaciones utilizan este flujo de trabajo para cambios estándar, es decir, publicaciones planificadas. Este flujo de trabajo también debe utilizarse para cambios urgentes o publicaciones no planificadas, aunque algunos equipos tienden a recortar presupuesto. Observa cómo la canalización de CD cierra automáticamente la solicitud de cambio cuando los errores la obligan a anular. Esto evita que se abandonen solicitudes de cambio en mitad del flujo de trabajo de canalización.

La siguiente ilustración plasma el workflow tratado en las fases de sistema de CD. Ten en cuenta que algunos pasos podrían requerir la intervención de personas, y estos pasos manuales se pueden ejecutar como parte de las puertas manuales en el canal. Una vez asignada en su totalidad, la visualización del canal se parece mucho a la del mapa del flujo de valor de tus versiones del producto.

Una vez certificado el sistema montado, deja el conjunto sin cambiar y promuévelo a la producción.

Tanto si los subsistemas se pueden implementar de forma independiente como si se pueden montar en un sistema, esos artefactos sometidos a control de versiones se implementan en la producción como parte de esta fase final.

La implementación sin tiempo de inactividad (ZDD) evita el tiempo de inactividad para los clientes, y se debe llevar a cabo desde las pruebas hasta la producción, pasando por el entorno de ensayo. La implementación azul-verde es una conocida técnica de ZDD en la que se implementan nuevos bits en una minúscula sección transversal de la población (llamada "verde"), mientras que todos los demás ignoran la parte "azul", que es la de los bits antiguos. Si las cosas se ponen feas, revierte todos a "azul" y muy pocos clientes se verán afectados, si se da el caso. Si todo va bien en "verde", cambia a todos lentamente de "azul" a "verde".

Sin embargo, veo que en determinadas organizaciones se hace un mal uso de las puertas manuales. Requieren equipos que obtengan aprobación manual en una reunión del comité de evaluación de cambios (CAB). En ocasiones, la razón es que se malinterpreta la segregación de tareas o la separación de dudas, y un departamento se lo transmite a otro buscando aprobación para avanzar. Asimismo, he visto a algunos autorizadores del CAB demostrar un conocimiento técnico básico de los cambios que van a producción, de modo que el proceso de aprobación manual se vuelve lento y monótono.

Una buena forma de explicar la diferencia entre la entrega continua y la implementación continua es decir que la entrega continua permite puertas manuales y la implementación continua, no. Aunque ambas se identifican con las siglas CD, la implementación continua requiere más disciplina y rigor, ya que no hay intervención humana en la canalización.

Existe una diferencia entre mover los bits y activarlos. Ejecuta pruebas de humo en la producción, que son un subconjunto de las series de pruebas de integración, rendimiento y seguridad. Una vez aprobadas las pruebas de humo, activa los bits, y el producto se publica para nuestros clientes.

El siguiente esquema ilustra los pasos que sigue el equipo en la fase final de entrega continua.

Para lograr el éxito en la entrega continua o en implementación continua, resulta fundamental llevar a cabo una integración y unas pruebas continuas. Partiendo de una base sólida, saldrás ganando en todos los conceptos: calidad, frecuentemente y de forma predecible.

Con una canalización de entrega continua, tus ideas se convierten en productos a través de una serie de experimentos sostenibles. Si descubres que tu idea no es tan buena como creías, puedes comenzar rápidamente con otra mejor. Además, las canalizaciones reducen las incidencias de producción de tiempo medio de resolución (MTTR), lo que reduce el tiempo de inactividad de tus clientes. Con la entrega continua, tendrás equipos productivos y clientes satisfechos, ¿qué más se puede pedir?

Sigue informándote con nuestro Tutorial sobre entrega continua.