Разработка на основе тестов для целевых зон Azure
Разработка на основе тестов (TDD) — это процесс разработки программного обеспечения и devOps, который улучшает качество новых функций и улучшений в решениях на основе кода. TDD создает модульные тестовые случаи перед разработкой фактического кода и проверяет код в тестовых случаях. Этот подход выступает против разработки кода в первую очередь и создания тестовых вариантов позже.
Целевая зона — это среда для размещения рабочих нагрузок, предварительно подготовленных с помощью кода. Целевые зоны включают базовые возможности, использующие определенный набор облачных служб и рекомендации. В этой статье описывается подход, который использует TDD для развертывания успешных целевых зон при выполнении требований к качеству, безопасности, операциям и управлению.
Облачная инфраструктура — это выходные данные выполнения кода. Хорошо структурированный, протестированный и проверенный код дает подходящую целевую зону. Облачная инфраструктура и базовый исходный код могут использовать этот подход для обеспечения высокого качества целевых зон и соответствия основным требованиям.
Используйте этот подход для удовлетворения простых запросов функций во время ранней разработки. Далее в жизненном цикле внедрения облака вы можете использовать этот процесс для удовлетворения требований к безопасности, операциям, управлению или соответствию требованиям. Этот процесс особенно полезен для разработки и рефакторинга целевых зон параллельной разработки.
Цикл разработки на основе тестирования
На следующей схеме показан цикл разработки на основе тестов для целевых зон Azure:
Создайте тест. Определите тест, чтобы проверить, выполнены ли критерии принятия функции. Автоматизируйте тест по мере разработки, чтобы сократить объем усилий вручную, особенно для развертываний корпоративного масштаба.
Проверьте целевую зону. Запустите новый тест и все существующие тесты. Если требуемая функция не включена в предложения поставщика облачных служб и не была предоставлена предыдущими усилиями по разработке, тест должен завершиться ошибкой. Выполнение существующих тестов помогает проверить, что новая функция или тест не снижает надежность существующих функций целевой зоны.
Разверните и рефакторинг целевой зоны. Добавьте или измените исходный код, чтобы выполнить запрошенную функцию добавления значений и повысить общее качество базы кода.
Чтобы соответствовать критериям TDD, команда облачной платформы добавит код только для удовлетворения запрошенной функции. Однако качество кода и обслуживание являются общими усилиями. По мере выполнения новых запросов функций команда облачной платформы должна попытаться улучшить код, удаляя дублирование и уточняя код. Выполнение тестов между созданием нового кода и рефакторингом исходного кода настоятельно рекомендуется.
Разверните целевую зону. Когда исходный код выполнит запрос функции, разверните измененную целевую зону в облачном поставщике в управляемой среде тестирования или песочницы.
Проверьте целевую зону. Повторно проверьте целевую зону, чтобы убедиться, что новый код соответствует критериям принятия запрошенной функции. После прохождения всех тестов функция считается завершенной и критерии принятия считаются выполнены.
Цикл TDD повторяет предыдущие основные шаги, пока они не соответствуют полному определению выполненных действий. Когда все функции, создающие добавочную стоимость, и условия приемки проходят соответствующие тесты, целевая зона готова к следующей волне плана по внедрению облачных технологий.
Цикл, который делает 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 Resource Graph предоставляет язык запросов для создания тестов на основе данных на основе сведений о ресурсах, развернутых в целевой зоне. Далее в плане внедрения это средство также может определять сложные тесты на основе взаимодействия между ресурсами рабочей нагрузки и базовой облачной средой.
Resource Graph включает расширенные примеры запросов, которые можно использовать для понимания того, как рабочие нагрузки развертываются в целевой зоне для сценариев расширенного тестирования.
В зависимости от предпочтительного подхода можно также использовать следующие средства:
- Развертывание целевых зон с помощью Terraform.
- Развертывание целевых зон с помощью Bicep.
- Управление целевыми зонами с помощью AzOps, модуля PowerShell, который отправляет шаблоны ресурсов и файлы Bicep на всех уровнях Azure область, а также извлекает и экспортирует иерархии ресурсов Azure.