Cerrar

Conceptos básicos sobre los canales 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?

How does a pipeline relate to continuous delivery (CD)? As the name suggests, a continuous delivery pipeline is an implementation of the continuous paradigm, where automated builds, tests and deployments are orchestrated as one release workflow. Put more plainly, a CD pipeline is a set of steps your code changes will go through to make their way to production.

A CD pipeline delivers, as per business needs, quality products frequently and predictably from test to staging to production in an automated fashion.

For starters, let’s focus on the three concepts: quality, frequently, and predictably.

We emphasize on quality to underscore that it’s not traded off for speed. Business doesn’t want us to build a pipeline that can shoot faulty code to production at high speed. We will go through the principles of “Shift Left” and “DevSecOps”, and discuss how we can move quality and security upstream in the SDLC (software development life cycle). This will put to rest any concerns regarding continuous delivery pipelines posing risk to businesses.

Frequently indicates that pipelines execute at any time to release features, since they are programmed to trigger with commits to the codebase. Once the pipeline MVP (minimum viable product) is in place, it can execute as many times as it needs to with periodic maintenance cost. This automated approach scales without burning out the team. This also allows teams to make small incremental improvements to their products without the fear of a major catastrophe in production.

Cliche as it may sound, the nation of “to err is human” still holds true. Teams brace for impact during manual releases since those processes are brittle. Predictably implies that releases are deterministic in nature when done via continuous delivery pipelines. Since pipelines are programmable infrastructure, teams can expect the desired behavior every time. Accidents can happen, of course, since no software is bug-free. However, pipelines are exponentially better than manual error-prone release processes, since unlike humans, pipelines don’t falter under aggressive deadlines.  

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.

Continuous delivery pipeline articles

[CONTINUED]

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:

Even if you foresee more than four phases or less than four in your organization, the concepts outlined below still apply.

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.

CD Component phase

The pipeline first builds components - the smallest distributable and testable units of the product. For example, a library built by the pipeline can be termed a component. A component can be certified, among other things, by code reviews, unit tests, and static code analyzers.

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!

Static code analysis detects problems in code without executing it. This is an inexpensive way to detect issues. Like unit tests, these tests run on source code and have low run-time. Static analyzers detect potential memory leaks, along with code quality indicators like cyclomatic complexity and code duplication. During this phase, SAST (static analysis security testing) is a proven way to discover security vulnerabilities.

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.

Subsystems can be deployed and certified by functional, performance, and security tests. Let’s study how each of these test types validate the product.

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) Certifying components and/or subsystems in the test environment

Fase de sistema de CD

Once subsystems meet functional, performance, and security expectations, the pipeline could be taught to assemble a system from loosely coupled subsystems in cases where the entire system has to be released as a whole. What that means is that the fastest team can go at the speed of the slowest team. Reminds me of the old saying, “A chain is only as strong as its weakest link”.

We recommend against this composition anti-pattern where subsystems are composed into a system to be released as a whole. This anti-pattern ties all the subsystems at their hips for success. If you invest in independently deployable artifacts, you will be able to avoid this anti-pattern.

Where systems need to be validated as a whole, they can be certified by integration, performance, and security tests. Unlike subsystem phase, do not use mocks or stubs during testing in this phase. Also, focus on testing interfaces and network more than anything else.

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.

The pipeline can automatically file change requests (CR) to leave an audit trail. Most organizations use this workflow for standard changes, which means, planned releases. This workflow should also be used for emergency changes, or unplanned releases, although some teams tend to cut corners. Note how the change request (CR) is closed automatically by the CD pipeline when errors force it to abort. This prevents CRs from being abandoned in the middle of the pipeline workflow.

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

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.

This is a good segway to call out the difference between continuous delivery and continuous deployment. Continuous delivery allows manual gates whereas continuous deployment doesn’t. While both are referred to as CD, continuous deployment requires more discipline and rigor since there is no human intervention in the pipeline.

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.

The following diagram illustrates the steps carried out by the team in this final phase of continuous delivery.

C) Certifying subsystems and/or system in the production environment

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.

A continuous delivery pipeline helps your ideas become products through a series of sustainable experiments. If you discover your idea isn’t as good as you thought it was, you can quickly turn around with a better idea. Additionally, pipelines reduce the MTTR (mean time to resolve) production issues, thus reducing downtime for your customers. With continuous delivery, you end up with productive teams and satisfied customers, and who doesn’t want that?

Learn more in our Continuous Delivery tutorial.

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.