Close

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

Descubre cómo se enlazan las compilaciones, pruebas e implementaciones automatizadas en el flujo de trabajo de una versión.

¿Qué es un canal de entrega continua?

¿Cómo se relaciona una canalización con la entrega continua (CD)? Como su nombre indica, una "canalización de entrega continua" es una implementación del paradigma continuo, donde las compilaciones, pruebas e implementaciones automatizadas se orquestan en un solo flujo de trabajo de publicación. Dicho más claramente, una canalización de CD es un conjunto de pasos por los que transcurrirán los cambios de código hasta llegar a la producción.

Una canalización de CD ofrece, según las necesidades del negocio, productos de calidad, con frecuencia y de forma predecible, desde la prueba o el entorno de ensayo hasta la producción de forma automatizada.

Para empezar, centrémonos en los siguientes tres conceptos: "calidad", "con frecuencia" y "predecible".

Hacemos hincapié en la "calidad" para subrayar que no la sustituimos por la velocidad. El negocio no quiere que compilemos una canalización capaz de generar e introducir código erróneo en la producción a gran velocidad. Analizaremos los principios del enfoque "Shift Left" y "DevSecOps", y veremos cómo podemos elevar la calidad y la seguridad en el ciclo de vida de desarrollo de software (SDLC). De esta forma, se disipan las preocupaciones acerca de las canalizaciones de entrega continua que supongan riesgos para los negocios.

"Con frecuencia" indica que las canalizaciones se ejecutan en cualquier momento para publicar funciones, ya que están programadas para desencadenarse con confirmaciones en el código base. Una vez que el producto mínimo viable (MVP) de canalización está listo, puede ejecutarse tantas veces como sea necesario con costes de mantenimiento periódicos. Este concepto automatizado se escala sin desgastar al equipo. También permite a los equipos realizar pequeñas mejoras incrementales en sus productos sin temor a una catástrofe importante en la producción.

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 un canal 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.

Artículos sobre la canalización de entrega continua

[CONTINUACIÓN]

Fases en un canal de entrega continua

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:

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 el canal. 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 del canal. 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 SDLC (ciclo de vida de desarrollo de software) y rechazaba las versiones 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 workflow de entrega continua. En estas próximas secciones, veremos cada fase detalladamente.

Fase de Componente de CD

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 incorrecto de forma que dejemos de creer que 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, SAST (pruebas de seguridad de análisis estático) es 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.

Fase de subsistema de CD

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 de tu producto. Integra tus pruebas de rendimiento con el canal, y usa las referencias de aprobación o fallo de los canales. Se suele creer que las pruebas de rendimiento no se deben integrar con los canales 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 detecten estos errores y hagan que el canal 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.

A) Certificación de componentes y/o subsistemas en el entorno de ensayo
CD Subsystem phase

Fase de sistema de CD

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 en aquellos casos en los que 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, céntrate sobre todo 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.

B) Certificación de subsistemas o sistemas en el entorno de ensayo
CD System phase

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

Fase de producción de CD

Ya se puedan implementar los subsistemas de forma independiente o se deban 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) es imprescindible para evitar 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".

Algunas organizaciones requieren una puerta manual (o dos) para que el canal se implemente en la producción. Hay casos en los que las puertas manuales son legítimas: las empresas pueden querer dirigirse a una determinada sección transversal geográfica o demográfica de la población y recopilar datos antes de publicarlos.

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 de cada a nuestros clientes.

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

C) Certificación de subsistemas y/o sistemas en el entorno de producción
CD Production phase

Entrega continua como la opción actual más habitual

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 previsiblemente.

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.

Juni Mukherjee
Juni Mukherjee

Juni is a thought citizen in the DevSecOps space and has made deep investments in the field of Continuous Delivery. She has helped organizations build Continuous Delivery Pipelines, and would love to solve the problems that plague our industry today. She has authored a couple of books.