Implementación y pruebas de cargas de trabajo críticas en Azure

Las implementaciones con errores y las versiones erróneas son causas comunes de interrupciones de aplicaciones. Su enfoque para la implementación y las pruebas desempeña un papel fundamental en la confiabilidad general de una aplicación crítica.

La implementación y las pruebas deben formar la base de todas las operaciones de aplicación e infraestructura para garantizar resultados coherentes para cargas de trabajo críticas. Prepárese para implementar semanalmente, diariamente o con más frecuencia. Diseñe las canalizaciones de integración continua e implementación continua (CI/CD) para admitir esos objetivos.

La estrategia debe implementar:

• Pruebas rigurosas de versión preliminar. Las actualizaciones no deben introducir defectos, vulnerabilidades u otros factores que puedan poner en peligro el estado de la aplicación.

• Implementaciones transparentes. Debe ser posible implementar actualizaciones en cualquier momento sin afectar a los usuarios. Los usuarios deben poder continuar sus interacciones con la aplicación sin interrupción.

• Operaciones de alta disponibilidad. Los procesos y las herramientas de implementación y pruebas deben ser de alta disponibilidad para admitir la confiabilidad general de las aplicaciones.

• Procesos de implementación coherentes. Los mismos artefactos y procesos de aplicación deben usarse para implementar la infraestructura y el código de aplicación en distintos entornos. La automatización de un extremo a otro es obligatoria. Las intervenciones manuales deben evitarse porque pueden introducir riesgos de confiabilidad.

En este área de diseño se proporcionan recomendaciones sobre cómo optimizar los procesos de implementación y pruebas con el objetivo de minimizar el tiempo de inactividad y mantener el estado y la disponibilidad de las aplicaciones.

Importante

Este artículo forma parte de la serie de cargas de trabajo críticas de Azure Well-Architected Framework. Si no está familiarizado con esta serie, se recomienda empezar con ¿Qué es una carga de trabajo crítica?.

Implementación sin tiempo de inactividad

Vea el vídeo siguiente para obtener información general sobre la implementación sin tiempo de inactividad.

Lograr implementaciones sin tiempo de inactividad es un objetivo fundamental para las aplicaciones críticas. La aplicación debe estar disponible todo el día, cada día, incluso cuando se implementan nuevas versiones durante el horario comercial. Invierta sus esfuerzos por adelantado para definir y planear los procesos de implementación con el fin de impulsar decisiones clave de diseño como si se tratan los recursos como efímeros.

Para lograr una implementación sin tiempo de inactividad, implemente una nueva infraestructura junto a la infraestructura existente, pruóbela exhaustivamente, realice la transición del tráfico del usuario final y, a continuación, retire la infraestructura anterior. Otras prácticas, como la arquitectura de la unidad de escalado, también son clave.

Las implementaciones de referencia de Mission-Critical Online y Azure Mission-Critical Connected ilustran este enfoque de implementación, como se muestra en este diagrama:

Entornos de aplicación.

Vea el vídeo siguiente para obtener información general sobre las recomendaciones para entornos de aplicación.

Necesita varios tipos de entornos para validar y realizar operaciones de implementación provisionales. Los tipos tienen diferentes funcionalidades y ciclos de vida. Algunos entornos podrían reflejar el entorno de producción y ser de larga duración, y otros podrían ser de corta duración y tener menos funcionalidades que la producción. La configuración de estos entornos al principio del ciclo de desarrollo ayuda a garantizar la agilidad, la separación de los recursos de producción y preproducción y las pruebas exhaustivas de las operaciones antes de su lanzamiento en el entorno de producción. Todos los entornos deben reflejar el entorno de producción tanto como sea posible, aunque puede aplicar simplificaciones a entornos inferiores según sea necesario. En este diagrama se muestra una arquitectura crítica:

Hay algunas consideraciones comunes:

• Los componentes no deben compartirse entre entornos. Las posibles excepciones son dispositivos de seguridad de nivel inferior, como firewalls y ubicaciones de origen para los datos de prueba sintéticos.

• Todos los entornos deben usar artefactos de infraestructura como código (IaC), como plantillas de Terraform o Azure Resource Manager (ARM).

Entornos de desarrollo

Vea el siguiente vídeo para obtener información sobre los entornos de desarrollo efímeros y la validación automatizada de características.

Consideraciones de diseño

• Funcionalidades. Los requisitos más bajos para la confiabilidad, la capacidad y la seguridad son aceptables para los entornos de desarrollo.

• Ciclo de vida. Los entornos de desarrollo deben crearse según sea necesario y existir durante un breve tiempo. Los ciclos de vida más cortos ayudan a evitar el desfase de configuración de la base de código y a reducir los costos. Además, los entornos de desarrollo suelen compartir el ciclo de vida de una rama de características.

• Densidad. Teams necesita varios entornos para admitir el desarrollo de características en paralelo. Pueden coexistir dentro de una sola suscripción.

Recomendaciones de diseño

• Mantenga el entorno en una suscripción dedicada con el contexto establecido para fines de desarrollo.

• Use un proceso automatizado para implementar código de una rama de características en un entorno de desarrollo.

Entornos de prueba o ensayo

Estos entornos se usan para pruebas y validación. Muchos ciclos de prueba se realizan para garantizar la implementación sin errores en producción. Las pruebas adecuadas para una carga de trabajo crítica se describen en la sección Validación y pruebas continuas .

Consideraciones de diseño

• Funcionalidades. Estos entornos deben reflejar el entorno de producción para la confiabilidad, la capacidad y la seguridad. En ausencia de una carga de producción, use una carga de usuario sintética para proporcionar métricas realistas y una entrada de modelado de estado valiosa.

• Ciclo de vida. Estos entornos son de corta duración. Deben destruirse una vez completadas las validaciones de prueba.

• Densidad. Puede ejecutar muchos entornos independientes en una suscripción. También debe considerar el uso de varios entornos, cada uno de ellos en una suscripción dedicada.

Nota:

Las aplicaciones críticas deben estar sujetas a pruebas rigurosas.

Puede realizar diferentes funciones de prueba en un único entorno y, en algunos casos, tendrá que hacerlo. Por ejemplo, para que las pruebas de caos proporcionen resultados significativos, primero debe colocar la aplicación bajo carga para que pueda comprender cómo responde la aplicación a los errores insertados. Por eso las pruebas de caos y las pruebas de carga se realizan normalmente en paralelo.

Recomendaciones de diseño

• Asegúrese de que al menos un entorno de ensayo refleje completamente la producción para habilitar pruebas y validación similares a la producción. La capacidad dentro de este entorno puede ajustarse en función de la ejecución de actividades de prueba.

• Genere una carga de usuario sintética para proporcionar un caso de prueba realista para los cambios en uno de los entornos.

  Nota:

  La implementación de referencia de Mission Critical Online proporciona un ejemplo de un generador de carga de usuarios.

• Defina el número de entornos de ensayo y sus propósitos dentro del ciclo de desarrollo y lanzamiento.

Entornos de producción

Consideraciones de diseño

• Funcionalidades. Se requieren los niveles más altos de confiabilidad, capacidad y funcionalidad de seguridad para la aplicación.

• Ciclo de vida. Aunque el ciclo de vida de la carga de trabajo y la infraestructura siguen siendo los mismos, todos los datos, incluida la supervisión y el registro, necesitan una administración especial. Por ejemplo, la administración es necesaria para la copia de seguridad y la recuperación.

• Densidad. Para algunas aplicaciones, es posible que quiera considerar el uso de entornos de producción diferentes para satisfacer diferentes clientes, usuarios o funcionalidades empresariales.

Recomendaciones de diseño

Tener un límite de gobernanza claro para entornos de producción e inferior. Coloque cada tipo de entorno en una suscripción dedicada para lograr ese objetivo. Esta segmentación garantiza que el uso de recursos en entornos inferiores no afecte a las cuotas de producción. Las suscripciones dedicadas también establecen límites de acceso.

Implementaciones azules-verdes transitorias

Un modelo de implementación azul/verde requiere al menos dos implementaciones idénticas. La implementación azul es la activa que atiende el tráfico de usuario en producción. La implementación verde es la nueva que está preparada y probada para recibir tráfico. Una vez completada y probada la implementación verde, el tráfico se dirige gradualmente de azul a verde. Si la transferencia de carga se realiza correctamente, la implementación verde se convierte en la nueva implementación activa. A continuación, la implementación azul antigua se puede retirar a través de un proceso por fases. Sin embargo, si hay problemas en la nueva implementación, se puede anular y el tráfico puede permanecer en la implementación azul anterior o redirigirse a ella.

Azure Mission-Critical recomienda un enfoque de implementación azul/verde en el que la infraestructura y las aplicaciones se implementan conjuntamente como parte de una marca de implementación. Por lo tanto, la implementación de un cambio en la infraestructura o la aplicación siempre da como resultado una implementación verde que contenga ambas capas. Este enfoque le permite probar y validar completamente el efecto del cambio en la infraestructura y la aplicación de un extremo a otro antes de redirigir el tráfico de usuario a él. El enfoque aumenta la confianza en la publicación de cambios y permite actualizaciones sin tiempo de inactividad porque se pueden validar las compatibilidades con dependencias de bajada, como la plataforma de Azure, los proveedores de recursos y los módulos de IaC.

Consideraciones de diseño

• Capacidades tecnológicas. Aproveche las características de implementación integradas en los servicios de Azure. Por ejemplo, App de Azure Service proporciona ranuras de implementación secundarias que se pueden intercambiar después de una implementación. Con Azure Kubernetes Service (AKS), puede usar una implementación de pod independiente en cada nodo y actualizar la definición del servicio.

• Duración de la implementación. La implementación puede tardar más tiempo en completarse porque la marca contiene la infraestructura y la aplicación en lugar de simplemente el componente modificado. Sin embargo, esto es aceptable porque el riesgo de que todos los componentes no funcionen según lo previsto invalidan los problemas de tiempo.

• Impacto en el costo. Hay un costo adicional debido a las dos implementaciones en paralelo, que deben coexistir hasta que se complete la implementación.

• Transición del tráfico. Una vez validada la nueva implementación, el tráfico debe pasar del entorno azul al verde. Esta transición requiere orquestación del tráfico de usuario entre los entornos. La transición debe estar totalmente automatizada.

• Ciclo de vida. Las marcas de implementación críticas deben considerarse efímeras. El uso de stamps de corta duración crea un inicio nuevo cada vez, antes de que se aprovisionan los recursos.

Recomendaciones de diseño

• Adopte un enfoque de implementación azul/verde para liberar todos los cambios de producción. Implemente toda la infraestructura y la aplicación cada vez, para cualquier tipo de cambio, para lograr un estado coherente y cero tiempo de inactividad. Aunque puede reutilizar entornos, no se recomienda para cargas de trabajo críticas. Trate cada marca de implementación regional como efímera con un ciclo de vida que esté vinculado a la de una sola versión.

• Use un equilibrador de carga global, como Azure Front Door, para orquestar la transición automatizada del tráfico de usuario entre los entornos azul y verde.

• Para realizar la transición del tráfico, agregue un punto de conexión de back-end verde que use un tráfico bajo al peso del volumen, como el 10 %. Después de comprobar que el volumen de tráfico bajo en la implementación verde funciona y proporciona el estado esperado de la aplicación, aumenta gradualmente el tráfico. Al hacerlo, aplique un breve período de rampa para detectar errores que podrían no ser evidentes inmediatamente.

  Después de realizar la transición de todo el tráfico, quite el back-end azul de las conexiones existentes. Por ejemplo, quite el back-end del servicio global del equilibrador de carga, las colas de purga y desasocie otras asociaciones. Esto ayuda a optimizar el costo de mantener la infraestructura de producción secundaria y a garantizar que los nuevos entornos estén libres de desfase de configuración.

  En este momento, retira el entorno azul antiguo y ahora inactivo. Para la siguiente implementación, repita el proceso con azul y verde invertido.

Implementación con ámbito de suscripción

En función de los requisitos de escalado de la aplicación, es posible que necesite varias suscripciones de producción para actuar como unidades de escalado.

Vea el vídeo siguiente para obtener información general sobre las recomendaciones para determinar el ámbito de las suscripciones para una aplicación crítica.

Consideraciones de diseño

• Escalabilidad. Para escenarios de aplicaciones a gran escala con volúmenes significativos de tráfico, diseñe la solución para escalar en varias suscripciones de Azure para que los límites de escala de una sola suscripción no restrinjan la escalabilidad.

  Importante

  El uso de varias suscripciones requiere una complejidad adicional de CI/CD, que debe administrarse adecuadamente. Por lo tanto, se recomiendan varias suscripciones solo en escenarios de escalado extremo, donde es probable que los límites de una sola suscripción se conviertan en una limitación.

• Límites del entorno. Implemente entornos de producción, desarrollo y pruebas en suscripciones independientes. Esta práctica garantiza que los entornos inferiores no contribuyan a los límites de escala. También reduce el riesgo de que las actualizaciones de menor entorno contaminen la producción al proporcionar una administración clara y un límite de identidad.

• Gobernanza. Cuando necesite varias suscripciones de producción, considere la posibilidad de usar un grupo de administración de aplicaciones dedicado para simplificar la asignación de directivas a través de un límite de agregación de directivas.

Recomendaciones de diseño

• Implemente cada marca de implementación regional en una suscripción dedicada para asegurarse de que los límites de la suscripción solo se aplican dentro del contexto de una sola marca de implementación y no en toda la aplicación. Cuando corresponda, puede considerar la posibilidad de usar varias marcas de implementación dentro de una sola región, pero debe implementarlas en suscripciones independientes.

• Coloque los recursos compartidos globales en una suscripción dedicada para habilitar la implementación coherente de la suscripción regional. Evite usar una implementación especializada para la región primaria.

Validación y pruebas continuas

Las pruebas son una actividad crítica que permite validar completamente el estado del código y la infraestructura de la aplicación. Más concretamente, las pruebas permiten cumplir los estándares de confiabilidad, rendimiento, disponibilidad, seguridad, calidad y escala. Las pruebas deben estar bien definidas y aplicadas como parte del diseño de la aplicación y la estrategia de DevOps. Las pruebas son una preocupación clave durante el proceso de desarrollador local (el bucle interno) y como parte del ciclo de vida completo de DevOps (el bucle externo), que es cuando el código se inicia en la ruta de acceso desde los procesos de canalización de versión hacia el entorno de producción.

Vea el vídeo siguiente para obtener información general sobre la validación y las pruebas continuas.

Esta sección se centra en las pruebas de bucles externos. Describe varios tipos de pruebas.

Prueba	Descripción
Pruebas unitarias	Confirma que la lógica de negocios de la aplicación funciona según lo previsto. Valida el efecto general de los cambios de código.
Pruebas de humo	Identifica si los componentes de la infraestructura y la aplicación están disponibles y funcionan según lo previsto. Normalmente, solo se prueba una sola sesión de usuario virtual. El resultado debe ser que el sistema responda con los valores y el comportamiento esperados. Entre los escenarios comunes de pruebas de humo se incluyen alcanzar el punto de conexión HTTPS de una aplicación web, consultar una base de datos y simular un flujo de usuario en la aplicación.
Pruebas de IU	Valida que las interfaces de usuario de la aplicación se implementan y que las interacciones de la interfaz de usuario funcionan según lo previsto. Debe usar herramientas de automatización de la interfaz de usuario para impulsar la automatización. Durante una prueba de IU, un script debe imitar un escenario de usuario realista y completar una serie de pasos para ejecutar acciones y lograr un resultado previsto.
Pruebas de carga	Valida la escalabilidad y la operación de la aplicación aumentando la carga rápidamente o gradualmente hasta que se alcanza un umbral predeterminado. Normalmente, las pruebas de carga se diseñan en torno a un flujo de usuario determinado para comprobar que los requisitos de la aplicación se cumplen con una carga definida.
Pruebas de estrés	Aplica actividades que sobrecargan los recursos existentes para determinar los límites de la solución y comprobar la capacidad del sistema para recuperarse correctamente. El objetivo principal es identificar posibles cuellos de botella de rendimiento y límites de escala. Por el contrario, escale verticalmente los recursos informáticos del sistema y supervise cómo se comporta bajo carga y determine si puede recuperarse.
Pruebas de rendimiento	Combina aspectos de las pruebas de carga y esfuerzo para validar el rendimiento bajo carga y establecer comportamientos de pruebas comparativas para la operación de la aplicación.
Pruebas de Caos	Inserta errores artificiales en el sistema para evaluar cómo reacciona y validar la eficacia de las medidas de resistencia, los procedimientos operativos y las mitigaciones. Apagar componentes de infraestructura, degradar el rendimiento y introducir errores de aplicación son ejemplos de pruebas que se pueden usar para comprobar que la aplicación reaccionará según lo esperado cuando se produzcan los escenarios.
Pruebas de penetración	Garantiza que una aplicación y su entorno cumplan los requisitos de una posición de seguridad esperada. El objetivo es identificar vulnerabilidades de seguridad. Las pruebas de seguridad pueden incluir dependencias de paquetes y cadenas de suministro de software de un extremo a otro, con análisis y supervisión de vulnerabilidades y exposiciones comunes conocidas (CVE).

Consideraciones de diseño

• Automatización. Las pruebas automatizadas son esenciales para validar los cambios en la aplicación o la infraestructura de forma oportuna y repetible.

• Orden de prueba. El orden en el que se realizan las pruebas es una consideración crítica debido a varias dependencias, como la necesidad de tener un entorno de aplicación en ejecución. La duración de la prueba también influye en el orden. Las pruebas con tiempos de ejecución más cortos deben ejecutarse anteriormente en el ciclo cuando sea posible para aumentar la eficacia de las pruebas.

• Límites de escalabilidad. Los servicios de Azure tienen límites flexibles y estrictos diferentes. Considere la posibilidad de usar pruebas de carga para determinar si un sistema corre el riesgo de superarlos durante la carga de producción esperada. Las pruebas de carga también pueden ser útiles para establecer los umbrales adecuados para el escalado automático. En el caso de los servicios que no admiten el escalado automático, las pruebas de carga pueden ayudarle a ajustar los procedimientos operativos automatizados.

  La incapacidad de los componentes del sistema, como los componentes de red activos o pasivos o las bases de datos, para escalar correctamente puede ser restrictivo. Las pruebas de esfuerzo pueden ayudar a identificar las limitaciones.

• Análisis del modo de error. La introducción de errores en la aplicación y la infraestructura subyacente y la evaluación del efecto es esencial para evaluar los mecanismos de redundancia de la solución. Durante este análisis, identifique el riesgo, el impacto y la amplitud del impacto (interrupción parcial o completa). Para obtener un análisis de ejemplo creado para la implementación de referencia de Mission Critical Online , consulte Riesgos de interrupción de componentes individuales.

• Supervisión. Debe capturar y analizar los resultados de las pruebas individualmente y agregarlos para evaluar las tendencias a lo largo del tiempo. Debe evaluar continuamente los resultados de las pruebas para obtener precisión y cobertura.

Recomendaciones de diseño

Vea el vídeo siguiente para ver cómo se pueden integrar las pruebas de resistencia con las canalizaciones de CI/CD de Azure DevOps.

• Asegúrese de la coherencia mediante la automatización de todas las pruebas en los componentes de la infraestructura y de la aplicación. Integre las pruebas en canalizaciones de CI/CD para organizarlas y ejecutarlas cuando corresponda. Para obtener información sobre las opciones de tecnología, consulte Herramientas de DevOps.

• Trate todos los artefactos de prueba como código. Deben mantenerse y controlarse la versión junto con otros artefactos de código de aplicación.

• Alinee el Acuerdo de Nivel de Servicio de la infraestructura de prueba con el Acuerdo de Nivel de Servicio para los ciclos de implementación y pruebas.

• Ejecute pruebas de humo como parte de cada implementación. Ejecute también pruebas de carga extensas junto con las pruebas de esfuerzo y caos para validar que se mantiene el rendimiento y la operabilidad de la aplicación.

  • Use perfiles de carga que reflejen patrones de uso máximo reales.
  • Ejecute experimentos de caos y pruebas de inyección de errores al mismo tiempo que las pruebas de carga.

  Sugerencia

  Azure Chaos Studio es un conjunto nativo de herramientas de experimentación de caos. Las herramientas facilitan la realización de experimentos de caos e insertan errores en los servicios de Azure y los componentes de la aplicación.

  Chaos Studio proporciona experimentos de caos integrados para escenarios de error comunes y admite experimentos personalizados que tienen como destino los componentes de la infraestructura y la aplicación.

• Si las interacciones de la base de datos, como la creación de registros, son necesarias para las pruebas de carga o humo, use cuentas de prueba que tengan privilegios reducidos y hagan que los datos de prueba sean separables del contenido real del usuario.

• Examine y supervise la cadena de suministro de software de un extremo a otro y las dependencias de paquetes para los CV conocidos.

  • Use Dependabot para repositorios de GitHub para asegurarse de que el repositorio está actualizado automáticamente con las versiones más recientes de paquetes y aplicaciones de las que depende.

Infraestructura como implementaciones de código

La infraestructura como código (IaC) trata las definiciones de infraestructura como código fuente controladas junto con otros artefactos de aplicación. El uso de IaC promueve la coherencia del código entre entornos, elimina el riesgo de error humano durante las implementaciones automatizadas y proporciona rastreabilidad y reversión. En el caso de las implementaciones azules o verdes, el uso de IaC con implementaciones totalmente automatizadas es imperativo.

Un repositorio de IaC crítico tiene dos definiciones distintas que se asignan a los recursos globales y regionales. Para obtener información sobre estos tipos de recursos, consulte el patrón de arquitectura principal.

Consideraciones de diseño

• Infraestructura repetible. Implemente cargas de trabajo críticas de forma que genere el mismo entorno cada vez. IaC debe ser el modelo principal.

• Automatización. Todas las implementaciones deben estar totalmente automatizadas. Los procesos humanos son propensos a errores.

Recomendaciones de diseño

• Aplique IaC, asegurándose de que todos los recursos de Azure se definen en plantillas declarativas y se mantienen en un repositorio de control de código fuente. Las plantillas se implementan y los recursos se aprovisionan automáticamente desde el control de código fuente a través de canalizaciones de CI/CD. No se recomienda el uso de scripts imperativos.

• Prohibir las operaciones manuales en todos los entornos. La única excepción es entornos de desarrollador totalmente independientes.

Herramientas de DevOps

El uso eficaz de las herramientas de implementación es fundamental para la confiabilidad general, ya que los procesos de DevOps afectan al diseño general de la función y la aplicación. Por ejemplo, las operaciones de conmutación por error y escalado pueden depender de la automatización proporcionada por las herramientas de DevOps. Los equipos de ingeniería deben comprender el efecto de la falta de disponibilidad de un servicio de implementación con respecto a la carga de trabajo general. Las herramientas de implementación deben ser confiables y de alta disponibilidad.

Microsoft proporciona dos conjuntos de herramientas nativos de Azure, Acciones de GitHub y Azure Pipelines, que pueden implementar y administrar eficazmente una aplicación crítica.

Consideraciones de diseño

• Capacidades tecnológicas. Las funcionalidades de GitHub y Azure DevOps se superponen. Puede usarlos juntos para obtener lo mejor de ambos. Un enfoque común es almacenar repositorios de código en GitHub.com o GitHub AE al usar Azure Pipelines para la implementación.

  Tenga en cuenta la complejidad que se agrega al usar varias tecnologías. Evalúe un conjunto de características enriquecido con respecto a la confiabilidad general.

• Disponibilidad regional. En términos de confiabilidad máxima, la dependencia en una sola región de Azure representa un riesgo operativo.

  Por ejemplo, por ejemplo, el tráfico se distribuye entre dos regiones: Región 1 y Región 2. La región 2 hospeda la instancia de herramientas de Azure DevOps. Supongamos que hay una interrupción en la región 2 y que la instancia no está disponible. La región 1 controla automáticamente todo el tráfico y necesita implementar unidades de escalado adicionales para proporcionar una buena experiencia de conmutación por error. Pero no podrá hacerlo debido a la dependencia de Azure DevOps en la región 2.

• Replicación de datos. Los datos, incluidos los metadatos, las canalizaciones y el código fuente, deben replicarse entre regiones.

Recomendaciones de diseño

• Ambas tecnologías se hospedan en una sola región de Azure, lo que podría hacer que la estrategia de recuperación ante desastres sea restrictiva.

  Acciones de GitHub es adecuada para las tareas de compilación (integración continua), pero puede que falte de características para tareas de implementación complejas (implementación continua). Dado el amplio conjunto de características de Azure DevOps, se recomienda para implementaciones críticas. Sin embargo, debe elegir después de evaluar los inconvenientes.

• Defina un Acuerdo de Nivel de Servicio de disponibilidad para herramientas de implementación y garantice la alineación con requisitos más amplios de confiabilidad de las aplicaciones.

• En escenarios de varias regiones que usan una configuración de implementación activa,pasiva o activa/activa, asegúrese de que las operaciones de orquestación y escalado de conmutación por error pueden seguir funcionando aunque los conjuntos de herramientas de implementación de la región primaria que hospedan no estén disponibles.

Estrategia de bifurcación

Hay muchos enfoques válidos para la bifurcación. Debe elegir una estrategia que garantice la máxima confiabilidad. Una buena estrategia permite el desarrollo paralelo, proporciona una ruta clara de desarrollo a producción y admite versiones rápidas.

Consideraciones de diseño

• Minimizar el acceso. Los desarrolladores deben realizar su trabajo en feature/* las ramas y fix/* . Estas ramas se convierten en puntos de entrada para los cambios. Las restricciones basadas en roles se deben aplicar a las ramas como parte de la estrategia de bifurcación. Por ejemplo, solo permite a los administradores crear ramas de versión o aplicar convenciones de nomenclatura para ramas.

• Proceso acelerado para emergencias. La estrategia de bifurcación debe permitir que las revisiones se combinen en main tan pronto como sea práctico. De este modo, las versiones futuras contienen la corrección y se evita la periodicidad del problema. Use este proceso solo para cambios menores que aborden problemas urgentes y úselo con moderación.

Recomendaciones de diseño

• Dé prioridad al uso de GitHub para el control de código fuente.

  Importante

  Cree una estrategia de bifurcación que detalla el trabajo y las versiones de características como mínimo, y use directivas y permisos de rama para asegurarse de que la estrategia se aplique correctamente.

• Desencadene un proceso de prueba automatizado para validar las contribuciones de cambios de código antes de que se acepten. Los miembros del equipo también deben revisar los cambios.

• Trate la main rama como una rama constantemente en movimiento y estable que se usa principalmente para las pruebas de integración.

  • Asegúrese de que los cambios se realicen solo a main través de solicitudes de incorporación de cambios. Use una directiva de rama para prohibir las confirmaciones directas.
  • Cada vez que una solicitud de incorporación de cambios se combina en main, debería iniciar automáticamente una implementación en un entorno de integración.
  • La main rama debe considerarse estable. Debe ser seguro crear una versión desde main en cualquier momento dado.

• Use ramas dedicadas release/* que se crean a partir de la main rama y se usan para implementar en entornos de producción. release/* las ramas deben permanecer en el repositorio y se pueden usar para aplicar revisiones a una versión.

• Documente un proceso de revisión y úselo solo cuando sea necesario. Cree revisiones en una fix/* rama para la combinación posterior en la rama de versión y la implementación en producción.

Inteligencia artificial para DevOps

Puede aplicar metodologías de AIOps en canalizaciones de CI/CD para complementar los enfoques de prueba tradicionales. Al hacerlo, se habilita la detección de posibles regresiones o degradaciones y se permite que las implementaciones se detengan de forma preventiva para evitar posibles impactos negativos.

Consideraciones de diseño

• Volumen de datos de telemetría. Las canalizaciones de CI/CD y los procesos de DevOps emiten una amplia variedad de telemetría para los modelos de aprendizaje automático. La telemetría va desde los resultados de las pruebas y los resultados de implementación hasta los datos operativos sobre los componentes de prueba de las fases de implementación compuestas.

• Escalabilidad. Es posible que los enfoques tradicionales de procesamiento de datos como Extraer, Transformar, Cargar (ETL) no puedan escalar el rendimiento para mantenerse al día con el crecimiento de los datos de telemetría de implementación y observabilidad de aplicaciones. Puede usar enfoques de análisis modernos que no requieran ETL y movimiento de datos, como la virtualización de datos, para habilitar el análisis continuo mediante modelos de AIOps.

• Cambios de implementación. Los cambios en la implementación deben almacenarse para el análisis automatizado y la correlación con los resultados de la implementación.

Recomendaciones de diseño

• Defina los datos de proceso de DevOps para recopilarlos y cómo analizarlos. La telemetría, como las métricas de ejecución de pruebas y los datos de series temporales de los cambios dentro de cada implementación, es importante.

  • Exponga datos de observabilidad de aplicaciones desde entornos de ensayo, prueba y producción para el análisis y la correlación dentro de los modelos de AIOps.

• Adopte el flujo de trabajo de MLOps.

• Desarrolle modelos analíticos que tengan en cuenta el contexto y que tengan en cuenta la dependencia para proporcionar predicciones con ingeniería automatizada de características para abordar los cambios de esquema y comportamiento.

• Poner en marcha los modelos mediante el registro e implementación de los modelos mejor entrenados en las canalizaciones de implementación.

Paso siguiente

Revise las consideraciones de seguridad.

Seguridad