Разработка на основе тестов для целевых зон Azure
Разработка на основе тестирования (TDD) — это процесс разработки программного обеспечения и DevOps, который повышает качество новых функций и улучшает решения на основе кода. TDD создает модульные тестовые случаи перед разработкой фактического кода и проверяет код на соответствие тестовых случаев. Этот подход отличается от разработки кода в первую очередь и создания тестовых случаев позже.
Целевая зона — это среда для размещения рабочих нагрузок, предварительно подготавливаемая с помощью кода. Целевые зоны включают базовые возможности, использующие определенный набор облачных служб и рекомендации. В этой статье описывается подход, который использует TDD для успешного развертывания целевых зон при выполнении требований к качеству, безопасности, эксплуатации и управлению.
Облачная инфраструктура — это выходные данные выполнения кода. Хорошо структурированный, протестированный и проверенный код дает подходящую целевую зону. Облачная инфраструктура и ее базовый исходный код могут использовать этот подход для обеспечения высокого качества целевых зон и соответствия основным требованиям.
Используйте этот подход для удовлетворения простых запросов функций во время ранней разработки. Позже в жизненном цикле внедрения облачных технологий вы сможете использовать этот процесс для удовлетворения требований к безопасности, эксплуатации, управлению или соответствию. Этот процесс особенно полезен для разработки и рефакторинга целевых зон в параллельной разработке.
Цикл разработки на основе тестирования
На следующей схеме показан цикл разработки на основе тестирования для целевых зон Azure.
Создайте тест. Определите тест, чтобы убедиться, что условия принятия для функции выполнены. Автоматизируйте тест по мере разработки, чтобы сократить объем выполняемых вручную тестов, особенно для развертываний корпоративного уровня.
Протестируйте целевую зону. Запустите новый тест и все существующие тесты. Если требуемая функция не включена в предложения поставщика облачных служб и не была предоставлена предыдущими усилиями по разработке, тест должен завершиться ошибкой. Выполнение существующих тестов помогает убедиться, что новый компонент или тест не снижает надежность существующих функций целевой зоны.
Разверните и рефакторинг целевой зоны. Добавьте или измените исходный код, чтобы выполнить запрошенную функцию добавления ценности и улучшить общее качество базы кода.
Чтобы соответствовать критериям TDD, команда облачной платформы добавит код только в соответствии с запрошенной функцией. Однако качество кода и обслуживание являются общими усилиями. По мере выполнения запросов на новые функции команда разработчиков облачной платформы должна попытаться улучшить код, удалив дублирование и уточнив код. Настоятельно рекомендуется выполнять тесты между созданием нового кода и рефакторингом исходного кода.
Разверните целевую зону. Когда исходный код выполнит запрос функции, разверните измененную целевую зону у поставщика облачных служб в управляемой тестовой среде или песочнице.
Протестируйте целевую зону. Повторно проверьте целевую зону, чтобы убедиться, что новый код соответствует критериям принятия для запрошенной функции. После прохождения всех тестов функция считается завершенной, а критерии приемки считаются выполненными.
Цикл TDD повторяет предыдущие основные шаги, пока они не соответствуют полному определению done. Когда все функции, создающие добавочную стоимость, и условия приемки проходят соответствующие тесты, целевая зона готова к следующей волне плана по внедрению облачных технологий.
Цикл, обеспечивающий эффективность TDD, часто называется красно-зеленым тестом. При таком подходе команда облачной платформы начинает с неудачного теста или красного теста на основе определения выполнено и определенных критериев принятия. Для каждой функции или условий принятия команда облачной платформы выполняет задачи разработки до тех пор, пока тест не пройдет или не будет выполнен зеленый тест.
Цель TDD заключается в улучшении проектирования, а не в создании набора тестов. Тесты являются ценным артефактом для завершения процесса.
Определение готовности
Успех может быть субъективным показателем, который предоставляет команде облачной платформы мало информации о действиях во время разработки или рефакторинга целевой зоны. Отсутствие ясности может привести к пропущенным ожиданиям и уязвимостям в облачной среде. Прежде чем команда облачной платформы рефакторингует или расширит какие-либо целевые зоны, ей следует искать ясность в отношении определения готового (DoD) для каждой целевой зоны.
DoD — это простое соглашение между командой облачной платформы и другими затронутыми командами, которое определяет ожидаемые функции с добавленной стоимостью, которые будут включены в разработку целевой зоны. DoD часто является контрольным списком, который соответствует краткосрочному плану внедрения облака.
По мере того как команды внедряют все больше рабочих нагрузок и облачных функций, DoD и условия принятия становятся все более сложными. В зрелых процессах ожидаемые признаки имеют свои собственные критерии принятия, чтобы обеспечить большую ясность. Если все функции с добавленной стоимостью соответствуют критериям принятия, целевая зона достаточно настроена, чтобы обеспечить успех текущей волны внедрения или выпуска.
Простой пример DoD
Для первоначальной миграции DoD может быть слишком простым. Ниже приведен простой пример DoD:
Начальная целевая зона будет размещать 10 рабочих нагрузок для начальных целей обучения. Эти рабочие нагрузки не являются критически важными для бизнеса и не имеют доступа к конфиденциальным данным. В будущем эти рабочие нагрузки, вероятно, будут выпущены в рабочую среду, но уровень важности и конфиденциальности не изменится.
Для поддержки этих рабочих нагрузок команда по внедрению облака должна соответствовать следующим критериям:
- Сегментация сети в соответствии с предлагаемой структурой сети. Эта среда должна быть сетью периметра с доступом к общедоступному Интернету.
- Доступ к вычислительным, сетевым ресурсам и ресурсам хранения для размещения рабочих нагрузок, согласованных с обнаружением цифровых активов.
- Схема именования и маркировки для простоты использования.
- Во время внедрения команда по внедрению облачных технологий может получить временный доступ к изменению конфигураций служб.
- До выпуска в рабочей среде интеграция с поставщиком корпоративных удостоверений для управления текущими удостоверениями и доступом для управления операциями. В это время доступ команды по внедрению облака должен быть отозван.
Последний пункт не является критерием функции или принятия, а индикатором того, что потребуется больше расширений, и их следует изучить с другими командами на ранних этапах.
Более сложные примеры DoD
Методология системы управления в Cloud Adoption Framework описывает путь с учетом естественной зрелости команды по системе управления. В этом пути встроено несколько примеров DoD и критериев принятия в виде политик.
Начальные инструкции политики. Пример первоначальной политики DoD на основе корпоративных политик, регулирующих требования к внедрению на ранней стадии.
Добавочные улучшения для расширения управления удостоверениями. Пример корпоративных политик, регулирующих DoD в соответствии с требованиями по расширению управления удостоверениями для целевой зоны.
Добавочные улучшения для расширения требований к безопасности. Пример корпоративных политик, регулирующих DoD в соответствии с требованиями безопасности, согласованными с планом внедрения эталонного облака.
Добавочные улучшения для расширения управления операциями. Пример корпоративных политик, регулирующих DoD для удовлетворения основных требований к управлению операциями.
Добавочные улучшения для расширения управления затратами. Пример корпоративных политик, регулирующих DoD в соответствии с требованиями к управлению затратами.
Предыдущие примеры являются основными примерами, которые помогут вам разработать DoD для целевых зон. Вы можете получить примеры политик для каждой из пяти дисциплин управления облаком.
Средства и функции Azure для поддержки TDD целевой зоны
На следующей схеме показаны доступные средства разработки на основе тестов в Azure:
Эти средства и функции Azure можно легко интегрировать в TDD для создания целевой зоны. Эти средства служат определенным целям, упрощая разработку, тестирование и развертывание целевых зон в соответствии с циклами TDD.
Azure Resource Manager предоставляет согласованную платформу для процессов сборки и развертывания. Платформа Resource Manager может развертывать целевые зоны на основе определений исходного кода.
Шаблоны Azure Resource Manager (ARM) предоставляют основной исходный код для сред, развернутых в Azure. Некоторые сторонние средства, такие как Terraform, предоставляют собственные шаблоны ARM для отправки в Azure Resource Manager.
Шаблоны быстрого запуска Azure предоставляют шаблоны исходного кода, которые помогают ускорить развертывание целевой зоны и рабочей нагрузки.
Политика Azure предоставляет основной механизм для тестирования критериев приемки в DoD. Политика Azure также может обеспечить автоматическое обнаружение, защиту и разрешение, если развертывания отклоняется от политик управления.
В цикле TDD можно создать определение политики для проверки одного условия принятия. Политика Azure включает встроенные определения политик, которые могут соответствовать отдельным критериям принятия в DoD. Такой подход предоставляет механизм для красных тестов перед изменением целевой зоны.
Политика Azure также включает встроенные инициативы политики, которые можно использовать для тестирования и применения полной версии DoD для целевой зоны. Вы можете добавить все критерии принятия в инициативу политики, назначенную всей подписке. После того как целевая зона соответствует требованиям DoD, Политика Azure может применить критерии теста, чтобы избежать изменений в коде, которые приведут к сбою теста в будущих выпусках.
Проектирование и проверка Политика Azure как рабочих процессов кода в рамках подхода TDD.
Azure Blueprints группирует политики и другие средства развертывания в повторяемый пакет, который можно назначить нескольким целевым зонам. Схемы полезны для нескольких усилий по внедрению, которые совместно используют общие doD, которые со временем может потребоваться обновить. Azure Blueprints также может помочь с развертыванием во время последующих усилий по расширению и рефакторингу целевых зон.
Azure Blueprints предоставляют различные примеры схем, включая политики для тестирования и шаблонов для развертывания. Эти примеры схем могут ускорить разработку, развертывание и тестирование в циклах TDD.
Azure Resource Graph предоставляет язык запросов для создания управляемых данными тестов на основе сведений о ресурсах, развернутых в целевой зоне. Далее в плане внедрения это средство также может определять сложные тесты на основе взаимодействия между ресурсами рабочей нагрузки и базовой облачной средой.
Resource Graph включает расширенные примеры запросов, которые можно использовать, чтобы понять, как рабочие нагрузки развертываются в целевой зоне для расширенных сценариев тестирования.
В зависимости от выбранного подхода можно также использовать следующие средства:
- Развертывание целевых зон с помощью Terraform.
- Развертывание целевых зон с помощью Bicep.
- Управление целевыми зонами с помощью AzOps, модуля PowerShell, который отправляет шаблоны ресурсов и файлы Bicep на всех уровнях Azure область, а также извлекает и экспортирует иерархии ресурсов Azure.