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 la aplicación. El 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:

• Rigurosas pruebas de versión preliminar. Novedades no debe 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 la 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 de tiempo de inactividad cero es un objetivo fundamental para las aplicaciones críticas. La aplicación debe estar disponible todo el día, todos los días, 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 de diseño clave como si tratar los recursos como efímeros.

Para lograr una implementación sin tiempo de inactividad, implemente una nueva infraestructura junto a la infraestructura existente, prulíquela 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 almacenar provisionalmente las operaciones de implementación. Los tipos tienen diferentes funcionalidades y ciclos de vida. Algunos entornos pueden 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 publicarlas 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 se deben compartir entre entornos. Las posibles excepciones son dispositivos de seguridad de bajada, como firewalls y ubicaciones de origen para 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ímero 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 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 valiosa entrada de modelado de estado.

• 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 flexibilizarse 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 usuario.

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

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. En 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 y inferiores. 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 efímeras azules/verdes

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. 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 completamente y validar el efecto del cambio en la infraestructura y la aplicación de un extremo a otro antes de redirigir el tráfico del usuario a él. El enfoque aumenta la confianza en la liberación de cambios y permite actualizaciones de tiempo de inactividad cero, ya que se pueden validar las compatibilidades con dependencias descendentes, 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, Azure App 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 la 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 aprovisionar 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 un tiempo de inactividad cero. 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 asociado al 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.

  Una vez que se realiza 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 de equilibrador de carga global, desagüe las colas 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 de 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 limiten la escalabilidad.

  Importante

  El uso de varias suscripciones requiere una complejidad adicional de CI/CD, que debe administrarse correctamente. 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 contribuyen a los límites de escala. También reduce el riesgo de que las actualizaciones de menor entorno contaminen la producción al proporcionar un límite claro de administración e 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 suscripción solo se aplican dentro del contexto de una sola marca de implementación y no en toda la aplicación. Si procede, 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. En concreto, las pruebas le 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 bucle externo. 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. Los escenarios comunes de prueba de humo incluyen llegar al 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 en una carga definida.
Pruebas de esfuerzo	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, reduzca 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 realmente 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 examen 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 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 activo/pasivo 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. Introducir errores en la aplicación y la infraestructura subyacente y evaluar el 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 ver 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 canalizaciones de CI/CD de Azure DevOps.

• Asegúrese de la coherencia mediante la automatización de todas las pruebas en componentes de infraestructura y aplicación. Integre las pruebas en canalizaciones de CI/CD para orquestar 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. Se deben mantener y controlar 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 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 se dirigen a componentes de infraestructura y aplicación.

• Si las interacciones de la base de datos, como la creación de registros, son necesarias para las pruebas de carga o de humo, use cuentas de prueba que tengan privilegios reducidos y hagan que los datos de prueba se puedan separar 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 los que depende.

Infraestructura como implementaciones de código

La infraestructura como código (IaC) trata las definiciones de infraestructura como código fuente controladas por la versión 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 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 una manera 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 mientras se usa 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 de una sola región de Azure representa un riesgo operativo.

  Por ejemplo, supongamos que el tráfico se distribuye en 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á 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 adecuado para las tareas de compilación (integración continua), pero podría faltar características para tareas de implementación complejas (implementación continua). Dado el amplio conjunto de características de Azure DevOps, se recomienda para las implementaciones críticas. Sin embargo, debe elegir después de evaluar las ventajas y desventajas.

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

• En escenarios de varias regiones que usan una configuración de implementación activa, pasiva o activa o activa, asegúrese de que las operaciones de orquestación y escalado de conmutación por error pueden seguir funcionando incluso si los conjuntos de herramientas de implementación de hospedaje de regiones primarias dejan de estar disponibles.

Estrategia de creación de ramas

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

• Minimice el acceso. Los desarrolladores deben realizar su trabajo en ramas feature/* 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 úselos con moderación.

Recomendaciones de diseño

• Priorice el uso de GitHub para el control de código fuente.

  Importante

  Cree una estrategia de bifurcación que detalle el trabajo de características y las versiones 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 rama principal como una rama continuamente en movimiento y estable que se usa principalmente para las pruebas de integración.

  • Asegúrese de que los cambios se realizan en main solo a 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 rama principal debe considerarse estable. Debe ser seguro crear una versión desde main en un momento dado.

• Use ramas dedicadas de versión/* que se crean a partir de la rama principal y que se usan para implementar en entornos de producción. Las ramas release/* 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 rama fix/* para la combinación posterior en la rama de versión y la implementación en producción.

IA para DevOps

Puede aplicar metodologías de AIOps en canalizaciones de CI/CD para complementar los enfoques de pruebas tradicionales. Al hacerlo, se permite la detección de posibles regresiones o degradaciones y 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 Extract, Transform, Load (ETL) no puedan escalar el rendimiento para mantenerse al día del crecimiento de los datos de telemetría de implementación y de observabilidad de aplicaciones. Puede usar enfoques de análisis modernos que no requieren ETL y movimiento de datos, como la virtualización de datos, para habilitar el análisis continuo por parte de los 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 del 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 los 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 sean compatibles con contexto y compatibles con dependencias para proporcionar predicciones con ingeniería de características automatizada para abordar los cambios de esquema y comportamiento.

• Operacionalice 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