Desarrollo controlado por pruebas para zonas de aterrizaje de Azure
El desarrollo controlado por pruebas (TDD) es un proceso de desarrollo de software y DevOps que mejora la calidad de las nuevas características y mejoras en las soluciones basadas en código. TDD crea casos de prueba unitaria antes de desarrollar el código real y prueba el código en los casos de prueba. Este enfoque se opone a desarrollar código primero y crear casos de prueba más adelante.
Una zona de aterrizaje es un entorno para hospedar cargas de trabajo que se aprovisionan previamente mediante código. Las zonas de aterrizaje incluyen funcionalidades fundamentales que usan un conjunto definido de servicios en la nube y procedimientos recomendados. En este artículo se describe un enfoque que usa TDD para implementar zonas de aterrizaje correctas al cumplir los requisitos de calidad, seguridad, operaciones y gobernanza.
La infraestructura en la nube es la salida de la ejecución de código. El código bien estructurado, probado y comprobado genera una zona de aterrizaje viable. La infraestructura basada en la nube y su código fuente subyacente pueden usar este enfoque para asegurarse de que las zonas de aterrizaje son de alta calidad y cumplen los requisitos principales.
Use este enfoque para satisfacer solicitudes de características sencillas durante el desarrollo temprano. Más adelante en el ciclo de vida de adopción de la nube, puede usar este proceso para cumplir los requisitos de seguridad, operaciones, gobernanza o cumplimiento. El proceso es especialmente útil para desarrollar y refactorizar zonas de aterrizaje en un esfuerzo de desarrollo paralelo.
Ciclo de desarrollo controlado por pruebas
En el diagrama siguiente se muestra el ciclo de desarrollo controlado por pruebas para las zonas de aterrizaje de Azure:
Cree una prueba. Defina una prueba para validar que se han cumplido los criterios de aceptación de una característica. Automatice la prueba a medida que desarrolle, para reducir la cantidad de esfuerzo de prueba manual, especialmente para las implementaciones a escala empresarial.
Pruebe la zona de aterrizaje. Ejecute la nueva prueba y las pruebas existentes. Si la característica necesaria no se incluye en las ofertas del proveedor de nube y no se ha proporcionado con los esfuerzos de desarrollo anteriores, la prueba debería producir un error. La ejecución de pruebas existentes ayuda a validar que la nueva característica o prueba no reduce la confiabilidad de las características existentes de la zona de aterrizaje.
Expanda y refactorice la zona de aterrizaje. Agregue o modifique el código fuente para cumplir la característica de value-add solicitada y mejorar la calidad general de la base de código.
Para cumplir los criterios de TDD, el equipo de la plataforma en la nube solo agregaría código para cumplir la característica solicitada. Sin embargo, la calidad y el mantenimiento del código son esfuerzos compartidos. A medida que cumplen nuevas solicitudes de características, el equipo de la plataforma en la nube debe intentar mejorar el código quitando la duplicación y aclarando el código. Se recomienda encarecidamente ejecutar pruebas entre la creación de código nuevo y la refactorización del código fuente.
Despliegue la zona de aterrizaje. Una vez que el código fuente cumple la solicitud de característica, implemente la zona de aterrizaje modificada en el proveedor de nube en un entorno de prueba o espacio aislado controlado.
Pruebe la zona de aterrizaje. Vuelva a probar la zona de aterrizaje para validar que el nuevo código cumple los criterios de aceptación de la característica solicitada. Una vez superadas todas las pruebas, la característica se considera completada y se consideran que se cumplen los criterios de aceptación.
En el ciclo de TDD, se repiten los pasos básicos anteriores hasta que se cumple la definición de Hecho completa. Cuando todas las características agregadas y los criterios de aceptación superan sus pruebas asociadas, la zona de aterrizaje está lista para admitir la siguiente oleada del plan de adopción de la nube.
El ciclo que hace que el desarrollo controlado por pruebas sea eficaz a menudo se conoce como prueba roja/verde. En este enfoque, el equipo de la plataforma en la nube comienza con una prueba fallida o prueba roja, en función de la definición de finalización y los criterios de aceptación definidos. Para cada característica o criterio de aceptación, el equipo de la plataforma en la nube completa las tareas de desarrollo hasta que se supere la prueba o tenga una prueba verde.
El objetivo de TDD es abordar un mejor diseño, no crear un conjunto de pruebas. Las pruebas son un artefacto valioso para completar el proceso.
Definición de terminado
El éxito puede ser una medida subjetiva que proporciona a un equipo de plataforma en la nube poca información accionable durante el desarrollo o la refactorización de zonas de aterrizaje. La falta de claridad puede provocar expectativas y vulnerabilidades perdidas en un entorno de nube. Antes de que el equipo de la plataforma en la nube refactorice o expanda cualquier zona de aterrizaje, debe tratar de aclarar la definición de Hecho (DoD) de cada zona de aterrizaje.
DoD es un acuerdo simple entre el equipo de la plataforma en la nube y otros equipos afectados que definen las características de valor añadido esperadas que se incluirán en el esfuerzo de desarrollo de la zona de aterrizaje. DoD es con frecuencia una lista de comprobación que se alinea con el plan de adopción de la nube a corto plazo.
A medida que los equipos adoptan más cargas de trabajo y características en la nube, el DoD y los criterios de aceptación se vuelven más complejos. En los procesos maduros, cada una de las características esperadas tiene sus propios criterios de aceptación para proporcionar más claridad. Cuando todas las características de valor agregado cumplen los criterios de aceptación, la zona de aterrizaje está suficientemente configurada para permitir el éxito de la oleada o versión de adopción actual.
Ejemplo de DoD simple
En los trabajos de migración iniciales, la DoD podría ser excesivamente simple. En el ejemplo siguiente, se muestra una DoD simple:
La zona de aterrizaje inicial hospedará 10 cargas de trabajo con fines de aprendizaje inicial. Estas cargas de trabajo no son críticas para la empresa y no tienen acceso a datos confidenciales. En el futuro, es probable que estas cargas de trabajo se publiquen en producción, pero no está previsto que cambie la importancia y la confidencialidad.
Para admitir estas cargas de trabajo, el equipo de adopción de la nube debe cumplir los siguientes criterios:
- Segmentación de red para alinearse con el diseño de red propuesto. Este entorno debe ser una red perimetral con acceso a la red pública de Internet.
- Acceda a recursos de proceso, almacenamiento y redes para hospedar las cargas de trabajo orientadas a la detección de patrimonio digital.
- Esquema de nomenclatura y etiquetado para facilitar el uso.
- Durante la adopción, acceso temporal para que el equipo de adopción de la nube modifique las configuraciones del servicio.
- Antes del lanzamiento en producción, es necesaria la integración con el proveedor de identidades corporativo para controlar la administración de las operaciones de identidad y acceso. En ese momento, se debe revocar el acceso al equipo de adopción de la nube.
El último punto no es un criterio de característica o aceptación, pero un indicador de que se requerirán más expansiones y que se deben explorar con otros equipos al principio.
Ejemplos de DoD más complejos
La metodología de gobernanza dentro de Cloud Adoption Framework proporciona un recorrido narrativo a través de la madurez natural de un equipo de gobernanza. Incluidos en ese recorrido, hay varios ejemplos de DoD y criterios de aceptación en forma de declaraciones de directivas.
Declaraciones de directivas iniciales. Ejemplo de DoD inicial basado en directivas corporativas que controlan los requisitos de adopción en la fase temprana.
Mejoras incrementales para expandir la gestión de identidades. Ejemplo de directivas corporativas que rigen el DoD para cumplir con los requisitos de ampliación de la gestión de identidades en una zona de aterrizaje.
Mejoras incrementales para expandir los requisitos de seguridad. Ejemplo de políticas corporativas que rigen el DoD para cumplir con los requisitos de seguridad alineados con el plan de adopción de la nube como referencia.
mejoras incrementales para expandir la administración de operaciones. Ejemplo de directivas corporativas que rigen doD para cumplir los requisitos básicos de administración de operaciones.
mejoras incrementales para expandir la administración de costos. Ejemplo de directivas corporativas que rigen doD para cumplir los requisitos de administración de costos.
Los ejemplos anteriores son ejemplos básicos que le ayudarán a desarrollar un DoD para las zonas de aterrizaje.
Herramientas y características de Azure que admiten el TDD de zona de aterrizaje
En el diagrama siguiente se muestran las herramientas de desarrollo controladas por pruebas disponibles en Azure:
Puede integrar fácilmente estas herramientas y características de Azure en TDD para la creación de zonas de aterrizaje. Las herramientas sirven con fines específicos, lo que facilita el desarrollo, la prueba y la implementación de zonas de aterrizaje en consonancia con los ciclos de TDD.
azure Resource Manager proporciona una plataforma coherente para procesos de compilación e implementación. La plataforma de Resource Manager puede implementar zonas de aterrizaje basadas en definiciones de código fuente.
Las plantillas de Azure Resource Manager (ARM) proporcionan el código fuente principal para entornos implementados en Azure. Algunas herramientas de terceros, como Terraform, proporcionan sus propias plantillas de ARM para enviarlas a Azure Resource Manager.
Las plantillas de inicio rápido de Azure proporcionan plantillas de código fuente que ayudan a acelerar la implementación de la zona de acogida y la carga de tareas.
Azure Policy proporciona el mecanismo principal para probar los criterios de aceptación en su DoD. Azure Policy también puede proporcionar detección, protección y resolución automatizadas cuando las implementaciones se desvía de las directivas de gobernanza.
En un ciclo de TDD, puede crear una definición de directiva para probar un único criterio de aceptación. Azure Policy incluye definiciones de directivas integradas que pueden cumplir criterios de aceptación individuales dentro de una DoD. Este enfoque proporciona un mecanismo para las pruebas rojas antes de modificar la zona de aterrizaje.
Azure Policy también incluye iniciativas de directivas integradas que se pueden usar para probar y aplicar la DoD completa para una zona de aterrizaje. Puede agregar todos los criterios de aceptación a una iniciativa de directiva asignada a toda la suscripción. Una vez que la zona de destino cumple con los requisitos de DoD, Azure Policy puede aplicar los criterios de prueba para evitar cambios en el código que harían que la prueba fallara en futuras versiones.
Como parte del enfoque de TDD, diseñe y revise Flujos de trabajo de Azure Policy como código.
Azure Resource Graph proporciona un lenguaje de consulta para crear pruebas controladas por datos en función de la información sobre los recursos implementados en una zona de aterrizaje. Más adelante en el plan de adopción, esta herramienta también puede definir pruebas complejas en función de las interacciones entre los recursos de carga de trabajo y el entorno de nube subyacente.
Resource Graph incluye ejemplos de consultas avanzadas , que puede usar para comprender cómo se implementan las cargas de trabajo dentro de una zona de aterrizaje para escenarios de prueba avanzados.
En función de su enfoque preferido, también puede usar las siguientes herramientas:
- Despliegue de zonas de aterrizaje mediante Terraform.
- Implementación de zonas de aterrizaje mediante Bicep.
- Administración de zonas de aterrizaje mediante AzOps: un módulo de PowerShell que inserta plantillas de recursos y archivos de Bicep en todos los niveles de ámbito de Azure, y extrae y exporta jerarquías de recursos de Azure.