Recomendaciones para diseñar una cadena de suministro de desarrollo de cargas de trabajo

  • Artículo

Se aplica a esta recomendación de lista de comprobación de excelencia operativa de Azure Well-Architected Framework:

OE:06 Cree una cadena de suministro de carga de trabajo que impulse los cambios propuestos a través de canalizaciones automatizadas predecibles. Las canalizaciones prueban y promueven esos cambios entre entornos. Optimice una cadena de suministro para que la carga de trabajo sea confiable, segura, rentable y eficaz.

En esta guía se describen las recomendaciones para diseñar una cadena de suministro de desarrollo de cargas de trabajo basada en canalizaciones de integración continua y entrega continua (CI/CD). Desarrolle una cadena de suministro para asegurarse de que tiene un método predecible y estandarizado para mantener la carga de trabajo. Las canalizaciones de CI/CD son la manifestación de la cadena de suministro, pero debe tener una sola cadena de suministro. Y es posible que tenga varias canalizaciones que sigan los mismos procesos y usen las mismas herramientas.

Incorpore una cadena de suministro para proteger la carga de trabajo frente a daños que pueden producirse cuando no administra correctamente los cambios de carga de trabajo. Tenga siempre en cuenta el estado de la carga de trabajo, por lo que no está en riesgo de experimentar un comportamiento imprevisible. Este riesgo se compone si necesita dedicar tiempo crítico a la retracción de los cambios cuando surjan problemas. Para minimizar estos riesgos, normalice los procesos y las herramientas que definen la cadena de suministro y asegúrese de que el equipo de cargas de trabajo se compromete completamente a su uso.

Definición

Término Definición
Cadena de suministro En las cargas de trabajo en la nube, una cadena de suministro es un conjunto estandarizado de herramientas y procesos que se usan para afectar al cambio de infraestructura y aplicación en todos los entornos.

Estrategias de diseño principales

Nota

Las recomendaciones de esta guía hacen referencia a los entornos de carga de trabajo de una cadena de promoción de código. El espacio aislado u otros entornos exploratorios y de prueba de concepto requieren menos rigor y estructura.

Conjuntos de principios principales

Las siguientes recomendaciones pueden ayudarle a definir los principios principales de la cadena de suministro.

Realice cambios de carga de trabajo propuestos a través de procesos y herramientas de la cadena de suministro. Aplique una directiva estricta de implementaciones automatizadas basadas en plantillas. Este método ayuda a garantizar que la configuración de la carga de trabajo en todos los entornos está estandarizada, bien definida y controlada estrechamente. Para entornos de una cadena de promoción de código, no realice actualizaciones mediante procesos manuales o interacción humana con el plano de control de la plataforma en la nube, por ejemplo, el portal o una API. Incorpore todos los cambios en el entorno a través de una canalización siguiendo las prácticas de implementación que defina. Para ayudar a aplicar esta directiva, considere la posibilidad de limitar el acceso a solo lectura como valor predeterminado y usar una puerta de autorización de acceso para permitir el acceso de escritura.

Un aspecto importante de esta red es que todos los cambios se proponenhasta que se implementan en producción. Mediante pruebas automatizadas, como la integración y las pruebas de humo, permite que la cadena de suministro rechace automáticamente los cambios.

Implemente una infraestructura repetible e inmutable como código (IaC). IaC es la administración de la infraestructura en un modelo descriptivo que usa un sistema de control de versiones que refleja el código fuente. Al crear una aplicación, el mismo código fuente debe generar el mismo binario cada vez que se compila. De forma similar, un modelo de IaC genera el mismo entorno cada vez que se aplica.

Incorpore IaC para asegurarse de que el equipo sigue un proceso estándar y bien establecido. Algunas organizaciones designan un único grupo individual o pequeño de individuos para implementar y configurar la infraestructura. Al implementar un proceso totalmente automatizado, las implementaciones de infraestructura requieren menos administración de usuarios. La responsabilidad se transfiere al proceso de automatización y a las herramientas. Los miembros del equipo pueden iniciar implementaciones de infraestructura para mantener la coherencia y la calidad.

Diseñe la carga de trabajo como un grupo lógico de componentes que puede agrupar en una plantilla para facilitar y repetir las implementaciones. Puede considerar estos paquetes como sellos o unidades de escala. Para obtener más información, consulte Patrón de stamps de implementación. Cuando necesite implementar la carga de trabajo para escalar horizontalmente en otra región o zona dentro de la misma región, implemente una marca mediante una canalización. En función de cómo diseñe los stamps, puede implementar un subconjunto de la carga de trabajo en lugar de toda la carga de trabajo. Incluya componentes de red en las canalizaciones de IaC para asegurarse de que las marcas de implementación se conectan automáticamente a los recursos existentes.

Para optimizar la canalización de IaC para lograr coherencia y eficacia, diseñe una infraestructura inmutable en lugar de una infraestructura mutable. Implemente una infraestructura inmutable para asegurarse de que todos los sistemas del ámbito se reemplazan por la configuración actualizada de forma simultánea e idéntica con cada implementación.

Use un conjunto de recursos de código y artefactos en todos los entornos y canalizaciones. Un punto de problema común para las organizaciones es cuando los entornos que no son de producción son diferentes de los entornos de producción. La creación manual de entornos de producción y no producción puede dar lugar a configuraciones no coincidentes entre los entornos. Esta falta de coincidencia ralentiza las pruebas y hace que sea más probable que los cambios puedan dañar un sistema de producción. Un enfoque de IaC minimiza estos problemas. Al usar la automatización de IaC, puede usar los mismos archivos de configuración de infraestructura para todos los entornos para generar entornos casi idénticos. Puede agregar parámetros a los archivos de configuración de infraestructura y ajustarlos para cumplir los requisitos de cada entorno.

Para controlar los costos, normalmente hay una varianza entre entornos de producción y no producción. A menudo no necesita el mismo grado de redundancia y rendimiento en entornos que no son de producción. El número y la SKU de los recursos pueden diferir entre los entornos. Asegúrese de controlar y comprender la varianza mediante el uso de parámetros estandarizados para ayudarle a mantener la previsibilidad a medida que realice cambios.

Refleje la estructura organizativa en los diseños de canalización y cadena de suministro. Es posible que su organización esté siloada entre los equipos. Cada equipo puede administrar una parte de la cadena de suministro. Por ejemplo, muchas organizaciones tienen equipos que administran dominios de infraestructura, como redes, datos y recursos de proceso. Estos equipos son independientes de los equipos de desarrollo que administran el desarrollo, las pruebas y las implementaciones de aplicaciones. En algunas organizaciones, los equipos de desarrollo e infraestructura se incorporan a los equipos de DevOps que administran colectivamente todas las implementaciones de infraestructura y aplicaciones. Hay muchas maneras de organizar los equipos implicados en una cadena de suministro. La cadena de suministro se basa en todos los equipos que trabajan juntos sin problemas. Asegúrese de que todos los equipos sigan los procesos estándar y usen herramientas estándar para que la cadena de suministro sea lo más eficaz posible.

La cadena de suministro puede depender de proveedores de terceros si externaliza partes del ciclo de vida de la carga de trabajo. Estos proveedores son tan críticos para el éxito de la cadena de suministro como recursos internos. Asegúrese de que haya un acuerdo mutuo entre todos los equipos sobre los procesos y las herramientas que use.

Estandarizar el método de implementación. Hable con el propietario del producto sobre la cantidad aceptable de tiempo de inactividad de producción para la carga de trabajo. Dependiendo de la cantidad, si existe, el tiempo de inactividad es aceptable, puede elegir el método de implementación adecuado para sus requisitos. Lo ideal es que realice implementaciones durante una ventana de mantenimiento para reducir la complejidad y el riesgo. Si no se acepta ningún tiempo de inactividad, emplee un método de implementación azul-verde.

Use un enfoque de exposición progresiva para reducir el riesgo de introducir errores no detectados a los clientes en general. También conocido como implementaciones controladas, este método se implementa en grupos controlados de usuarios en una secuencia gradual. Detecta problemas antes de que afecten a más usuarios. El grupo de lanzamiento inicial podría ser una subsección de los clientes que conocen la estrategia de lanzamiento. Esta subsección de clientes puede tolerar cierta cantidad de comportamiento inesperado y proporcionar comentarios. O puede ser un grupo de usuarios internos, que ayuda a contener el radio de explosión de errores durante el lanzamiento.

Al definir el método de implementación, adopte una directiva estándar de solo implementar el cambio viable más pequeño en cada implementación. En función de factores como la importancia de la carga de trabajo y la complejidad de los componentes, determine el cambio viable más pequeño. Si usa una infraestructura inmutable, el cambio viable más pequeño suele ser la implementación de recursos con la configuración más reciente para reemplazar los recursos que ejecutan la versión anterior. Si usa una infraestructura mutable, puede decidir que el cambio viable más pequeño es solo una actualización única en el grupo de recursos del ámbito.

Siga un enfoque por capas para reflejar diferentes ciclos de vida. Las capas fundamentales deben permanecer estáticas durante la mayor parte del ciclo de vida de la carga de trabajo y las capas de aplicación cambian con frecuencia. Para tener en cuenta estas diferencias, debe tener canalizaciones diferentes para aplicar cambios en cada capa.

Una zona de aterrizaje está en la capa más baja. Una zona de aterrizaje es una agrupación lógica de elementos fundamentales, como suscripciones, grupos de administración, grupos de recursos, funciones de gobernanza y topología de red. Una zona de aterrizaje le permite implementar y administrar fácilmente la carga de trabajo, y proporciona equipos de operaciones centrales, o equipos de plataforma, con un enfoque repetible para una configuración ambiental. Para ofrecer entornos coherentes, todas las zonas de aterrizaje de Azure proporcionan un conjunto de áreas de diseño comunes, una arquitectura de referencia, una implementación de referencia y un proceso para modificar una implementación para ajustarse a los requisitos de diseño. Los principios de diseño de la zona de aterrizaje de Azure proporcionan prácticas recomendadas basadas en la gobernanza controlada por directivas junto con la democratización de la suscripción. Una zona de aterrizaje debe requerir cambios mínimos durante el ciclo de vida de la carga de trabajo. Para ver un ejemplo de una zona de aterrizaje, consulte ¿Qué es una zona de aterrizaje de Azure? Esta arquitectura conceptual proporciona un conjunto de opiniones recomendadas para Azure.

La infraestructura y las funciones principales, como los controladores de red de entrada y salida, el equilibrio de carga, las soluciones de enrutamiento de red, la administración de DNS y los servidores principales, también deben requerir cambios importantes poco frecuentes. Sin embargo, pueden requerir actualizaciones frecuentes de configuración.

La capa de datos y la aplicación requieren actualizaciones de configuración frecuentes y cambios frecuentes en la infraestructura. Estos componentes deben tener las canalizaciones más dinámicas.

Planee una estrategia de pruebas holísticas. Una red central de confiabilidad del sistema es el principio de desplazamiento a la izquierda . El desarrollo e implementación de una aplicación es un proceso que se representa como una serie de pasos que van de izquierda a derecha. No debe limitar las pruebas al final del proceso. Tanto como sea posible, cambie las pruebas al principio o a la izquierda. Los errores son más baratos de reparar cuando los detecta temprano. Pueden ser costosos o imposibles de corregir más adelante en el ciclo de vida de la aplicación.

Pruebe todo el código, incluido el código de aplicación, las plantillas de infraestructura y los scripts de configuración. El entorno que ejecuta aplicaciones debe controlar la versión e implementarse a través de los mismos mecanismos que el código de aplicación. Puede probar y validar el entorno mediante los mismos paradigmas de prueba que los equipos ya usan para el código de aplicación.

Cuando sea posible, use pruebas automatizadas para garantizar la coherencia. Incluya los siguientes tipos de pruebas en el diseño de la cadena de suministro.

  • Pruebas unitarias: las pruebas unitarias se suelen ejecutar como parte de una rutina de integración continua. Las pruebas unitarias deben ser extensas y rápidas. Lo ideal es que cubran el 100 por ciento del código y se ejecuten en menos de 30 segundos.

    Implemente pruebas unitarias para comprobar que la sintaxis y la funcionalidad de los módulos individuales del código funcionan de la manera en que deben, por ejemplo, generar una salida definida para una entrada conocida. También puede usar pruebas unitarias para comprobar que los recursos de IaC son válidos.

    Aplique pruebas unitarias a todos los recursos de código, incluidas las plantillas y los scripts.

  • Pruebas de humo: las pruebas de humo comprueban que una carga de trabajo se puede levantar en un entorno de prueba y funciona según lo previsto. Las pruebas de humo no comprueban la interoperabilidad de los componentes.

    Las pruebas de humo comprueban que la metodología de implementación de la infraestructura y la aplicación funcionan, y que el sistema responde según lo previsto después de que finalice el proceso.

  • Pruebas de integración: las pruebas de integración garantizan que los componentes de la aplicación funcionan individualmente y, a continuación, determinan si los componentes pueden interactuar entre sí como deberían.

    Puede tardar mucho tiempo en ejecutar un conjunto de pruebas de integración grande. Es por eso que es mejor incorporar el principio izquierdo de desplazamiento y realizar pruebas al principio del ciclo de vida de desarrollo de software. Reserve pruebas de integración para escenarios que no se pueden probar con una prueba de humo o una prueba unitaria.

    Puede ejecutar procesos de prueba de larga duración en un intervalo regular si es necesario. Un intervalo regular ofrece un buen riesgo y detecta problemas de interoperabilidad entre los componentes de la aplicación a más tardar un día después de su introducción.

    Algunos escenarios de prueba se benefician de las ejecuciones manuales. Use pruebas manuales cuando necesite introducir elementos de interactividad humana en pruebas.

  • Pruebas de aceptación: dependiendo del contexto, puede realizar manualmente pruebas de aceptación. Puede ser parcialmente o totalmente automatizado. Las pruebas de aceptación determinan si el sistema de software cumple las especificaciones de requisitos.

    El objetivo principal de esta prueba es evaluar el cumplimiento del sistema con los requisitos empresariales y determinar si el sistema cumple los criterios necesarios para la entrega a los usuarios finales.

Implemente puertas de calidad en todo el proceso de promoción de código a través de pruebas. Implemente el código en entornos inferiores, como desarrollo y pruebas, y hasta entornos superiores, como el almacenamiento provisional y la producción. A medida que la implementación pasa por puertas de calidad, asegúrese de que cumple los objetivos de calidad antes de que los cambios pasen a producción. Sus requisitos empresariales determinan cuál es el enfoque de sus puertas de calidad. Tenga en cuenta también los principios fundamentales del marco de Well-Architected: Seguridad, Confiabilidad y Eficiencia del rendimiento.

Integre también los flujos de trabajo de aprobación en las puertas de calidad. Defina y automatice claramente los flujos de trabajo de aprobación cuando corresponda. Defina los criterios de aceptación de calidad en la automatización, por lo que puede desplazarse por sus puertas de forma eficaz y segura.

Facilitación de Azure

Azure DevOps es una colección de servicios que le ayudan a crear una práctica de desarrollo colaborativa, eficaz y coherente.

Azure Pipelines proporciona servicios de compilación y versión para admitir CI/CD en las aplicaciones.

Acciones de GitHub para Azure se integra con Azure para simplificar las implementaciones. Use Acciones de GitHub para automatizar procesos de CI/CD. Puede crear flujos de trabajo que compilen y prueben cada solicitud de incorporación de cambios en el repositorio o implementar solicitudes de incorporación de cambios combinadas en producción.

Puede usar Terraform, Bicep y Azure Resource Manager para las implementaciones de IaC. Según sus requisitos y la familiaridad de su equipo con las herramientas, puede usar una o varias de estas herramientas para las implementaciones y la administración de los recursos.

Ejemplo

Para ver un ejemplo que muestra cómo usar Azure Pipelines para compilar una canalización de CI/CD, consulte Arquitectura de línea base de Azure Pipelines.

Lista de comprobación de excelencia de operaciones

Consulte el conjunto completo de recomendaciones.

Lista de comprobación de excelencia operativa