Desarrollo controlado por pruebas para zonas de aterrizaje de Azure
El desarrollo controlado por pruebas (TDD) es un proceso de DevOps y de desarrollo de software que optimiza la calidad de las nuevas características y mejoras de las soluciones basada en código. TDD crea casos de prueba unitaria antes de desarrollar el código real y prueba el código con los casos de prueba. Este enfoque es lo contrario al desarrollo primero del código y la creación de casos de prueba posteriormente.
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 básicas que usan un conjunto definido de servicios en la nube y procedimientos recomendados. En este artículo se describe un enfoque donde se usa TDD para implementar zonas de aterrizaje correctas que cumplan los requisitos de calidad, seguridad, operaciones y gobernanza.
La infraestructura en la nube es la salida de la ejecución del código. El código bien estructurado, probado y verificado genera una zona de aterrizaje viable. La infraestructura basada en la nube y su código fuente subyacente pueden utilizar este enfoque para garantizar que las zonas de aterrizaje sean de alta calidad y cumplan los requisitos principales.
Use este enfoque para satisfacer las solicitudes de características simples durante las primeras fases del desarrollo. Más adelante en el ciclo de vida de adopción de la nube, puede usar este proceso para satisfacer los requisitos de seguridad, operaciones, gobernanza o cumplimiento. El proceso es especialmente útil para desarrollar y refactorizar zonas de aterrizaje en un trabajo 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:
Crear una prueba. Defina una prueba para validar que se han cumplido los criterios de aceptación de una característica. Automatice la prueba durante el desarrollo para reducir la cantidad de trabajo de prueba manual, especialmente para las implementaciones a escala empresarial.
Probar la zona de aterrizaje. ejecute la prueba nueva y las existentes. Si la característica necesaria no se incluye en las ofertas del proveedor de nube y no se ha proporcionado en los trabajos de desarrollo anteriores, la prueba producirá errores. La ejecución de pruebas existentes ayuda a validar que la nueva característica o prueba no reduce la confiabilidad de las características de la zona de aterrizaje existentes.
Expandir y refactorizar la zona de aterrizaje. Agregue o modifique el código fuente para satisfacer la característica de valor agregado solicitada y mejorar la calidad general de la base de código.
Para satisfacer los criterios de TDD, el equipo de la plataforma en la nube solo agregaría código para satisfacer la característica solicitada. Sin embargo, la calidad y el mantenimiento del código son trabajos compartidos. A medida que satisfacen las nuevas solicitudes de características, el equipo de la plataforma en la nube debe mejorar el código eliminando duplicados y dotándolo de una mayor claridad. Se recomienda encarecidamente ejecutar pruebas entre la creación de código nuevo y la refactorización del código fuente.
Implementar la zona de aterrizaje. Cuando el código fuente satisfaga la solicitud de la característica, implemente la zona de aterrizaje modificada en el proveedor de nube en un entorno de espacio aislado o de pruebas controlado.
Probar la zona de aterrizaje. Pruebe de nuevo la zona de aterrizaje para validar que el nuevo código satisfaga los criterios de aceptación de la característica solicitada. Una vez que se superen todas las pruebas, la característica se considera completada y que cumple 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 de valor añadido y los criterios de aceptación superen las pruebas asociadas, la zona de aterrizaje estará 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 errónea, o prueba roja, en función de la definición de finalización y de 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 del TDD es obtener un mejor diseño, no crear un conjunto de pruebas. Las pruebas son un artefacto valioso para completar el proceso.
Definición de finalizado
El éxito puede ser una medida objetiva que proporciona a un equipo de plataforma en la nube poca información procesable durante el desarrollo o la refactorización de la zona de aterrizaje. Esta falta de claridad puede dar lugar a unas expectativas insuficientes y a vulnerabilidades en un entorno de nube. Antes de que el equipo de la plataforma en la nube refactorice o expanda cualquier zona de aterrizaje, deben tratar de aclarar la definición de Hecho (DoD) de cada zona de aterrizaje.
DoD es un acuerdo sencillo entre el equipo de la plataforma en la nube y otros equipos afectados que define las características de valor agregado esperadas que se incluirán en el trabajo 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 adopten más cargas de trabajo y características de nube, la definición de Hecho y los criterios de aceptación se volverán cada vez más complejos. En los procesos consolidados, las características esperadas tienen sus propios criterios de aceptación para proporcionar más claridad si cabe. Cuando todas características de valor agregado cumplan los criterios de aceptación, significará que la zona de aterrizaje está lo bastante configurada como para permitir el éxito de la oleada o el lanzamiento actual de la adopción.
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 necesitará que se cumplan los siguientes criterios:
- Segmentación de la red que se alineará con el diseño de la red propuesto. Este entorno debe ser una red perimetral con acceso a la red pública de Internet.
- Acceso a recursos de proceso, almacenamiento y redes para hospedar las cargas de trabajo orientadas a la detección de patrimonio digital.
- Asignación de un nombre al esquema y etiquetado de este para facilitar su uso.
- Durante la adopción, acceso temporal para que el equipo de adopción de la nube cambie las configuraciones de los servicios.
- Antes del lanzamiento en producción, 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 una característica ni un criterio de aceptación, sino un indicador de que se necesitarán más expansiones y que se deben explorar con otros equipos en breve.
Ejemplos de DoD más compleja
La metodología de gobernanza de Cloud Adoption Framework proporciona un recorrido narrativo a través de la consolidación natural de un equipo de gobernanza. Insertados 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 administración de identidades. Ejemplo de directivas corporativas que controlan que DoD cumpla los requisitos para expandir la administración de identidades de una zona de aterrizaje.
Mejoras incrementales para expandir los requisitos de seguridad. Ejemplo de directivas corporativas que controlan que DoD cumpla los requisitos de seguridad que se alinean con el plan de adopción de la nube de referencia.
Mejoras incrementales para expandir la administración de operaciones. Ejemplo de directivas corporativas que controlan que DoD cumpla los requisitos básicos de administración de operaciones.
Mejoras incrementales para expandir la administración de costos. Ejemplo de directivas corporativas que controlan que DoD cumpla los requisitos de administración de costos.
Los ejemplos anteriores son ejemplos básicos que ayudan a desarrollar una DoD para las zonas de aterrizaje. Puede obtener directivas de ejemplo de cada una de las cinco disciplinas de gobernanza de la nube.
Herramientas y características de Azure que admiten el TDD de zona de aterrizaje
En el diagrama siguiente se muestran las herramientas de desarrollo controlado 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. Estas herramientas sirven a propósitos 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 los procesos de compilación e implementación. Esta plataforma 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 de cualquier entorno implementado en Azure. Algunas herramientas de terceros, como Terraform, generan sus propias plantillas de ARM que se envían 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 cargas de trabajo y zonas de aterrizaje.
Azure Policy proporciona el mecanismo principal para probar los criterios de aceptación en la de la DoD. Azure Policy también puede proporcionar detección, protección y resolución automatizadas cuando las implementaciones se desvían de las directivas de gobernanza.
En un ciclo de TDD, se 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 "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 aterrizaje cumple la DoD, Azure Policy puede aplicar los criterios de prueba con el fin de evitar cambios en el código que podrían provocar errores en la prueba en futuras versiones.
Como parte del enfoque de TDD, diseñe y revise Flujos de trabajo de Azure Policy como código.
Azure Blueprints agrupa las directivas y otras herramientas de implementación en un paquete repetible que se puede asignar a varias zonas de aterrizaje. Los planos técnicos son útiles para varios trabajos de adopción que comparten DoD comunes, que es posible que quiera actualizar con el tiempo. Azure Blueprints también puede ayudar con la implementación durante los trabajos subsiguientes para expandir y refactorizar las zonas de aterrizaje.
Azure Blueprints proporciona varios ejemplos de planos técnicos que incluyen directivas para las pruebas y plantillas para la implementación. Estos ejemplos de plano técnico pueden acelerar los esfuerzos de desarrollo, implementación y pruebas en ciclos de TDD.
Azure Resource Graph proporciona un lenguaje de consulta para crear pruebas controladas por datos basadas en 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 basadas en las interacciones entre los recursos de carga de trabajo y el entorno en la nube subyacente.
Resource Graph incluye muestras de consulta avanzadas que se pueden usar para entender cómo se implementan las cargas de trabajo en una zona de aterrizaje para escenarios de prueba avanzados.
En función de su enfoque preferido, también puede usar las siguientes herramientas:
- Implementación de zonas de aterrizaje de mediante Terraform.
- Implementación de zonas de aterrizaje de 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.