Поделиться через

Разработка на основе тестов для целевых зон Azure

  • Статья

Разработка на основе тестов (TDD) — это процесс разработки программного обеспечения и devOps, который улучшает качество новых функций и улучшений в решениях на основе кода. TDD создает модульные тестовые случаи перед разработкой фактического кода и проверяет код в тестовых случаях. Этот подход выступает против разработки кода в первую очередь и создания тестовых вариантов позже.

целевая зона — это среда для размещения рабочих нагрузок, предварительно подготовленных с помощью кода. Зоны приземления включают базовые возможности, использующие определенный набор облачных служб и передовые методы. В этой статье описывается подход, который использует TDD для развертывания успешных зон приземления при удовлетворении требований к качеству, безопасности, операциям и управлению.

Облачная инфраструктура — это выходные данные выполнения кода. Хорошо структурированный, протестированный и проверенный код создает жизнеспособную посадочную площадку. Облачная инфраструктура и базовый исходный код могут использовать этот подход для обеспечения высокого качества целевых зон и соответствия основным требованиям.

Используйте этот подход для удовлетворения простых запросов функций во время ранней разработки. Далее в жизненном цикле внедрения облака вы можете использовать этот процесс для удовлетворения требований к безопасности, операциям, управлению или соответствию требованиям. Этот процесс особенно полезен для разработки и рефакторинга высадочных зон при параллельной разработке.

Цикл разработки на основе тестов

На следующей схеме показан цикл разработки с тестированием для зон высадки Azure.

схема процесса разработки на основе тестов для целевых зон Azure.

  1. Создайте тест. Определите тест, чтобы проверить, выполнены ли критерии принятия функции. Автоматизируйте тест по мере разработки, чтобы сократить объем усилий вручную, особенно для развертываний корпоративного масштаба.

  2. Проверьте целевую зону. Запустите новый тест и все существующие тесты. Если требуемая функция не включена в предложения облачного провайдера и не была реализована в предыдущих усилиях по разработке, тест должен завершиться ошибкой. Выполнение существующих тестов помогает проверить, что новая функция или тест не снижает надежность существующих функций целевой зоны.

  3. Разверните и отрефакторируйте посадочную зону. Добавьте или измените исходный код, чтобы выполнить запрошенную функцию добавления значений и повысить общее качество базы кода.

    Чтобы соответствовать критериям TDD, команда облачной платформы добавит код только для удовлетворения запрошенной функции. Однако качество кода и обслуживание являются общими усилиями. По мере выполнения новых запросов функций команда облачной платформы должна попытаться улучшить код, удаляя дублирование и уточняя код. Выполнение тестов между созданием нового кода и рефакторингом исходного кода настоятельно рекомендуется.

  4. Разверните посадочную площадку. Когда исходный код удовлетворяет запрос на функцию, разверните измененную целевую зону размещения у облачного провайдера в управляемой среде тестирования или песочницы.

  5. Проверьте посадочную зону. Повторно протестируйте зону посадки, чтобы убедиться, что новый код соответствует критериям приемки запрошенной функциональности. После прохождения всех тестов функция считается завершенной и критерии принятия считаются выполнены.

Цикл TDD повторяет предыдущие основные шаги до тех пор, пока они не будут соответствовать полному определению “done”. Когда все ценные функции и критерии принятия успешно проходят свои тесты, зона высадки готова к поддержке следующей волны плана внедрения облачных решений.

Цикл, который делает TDD эффективным, часто называется красным и зеленым тестом. В этом подходе команда облачной платформы начинает с неудавшегося теста, или «красного» теста, на основе определения завершённости и определённых критериев приемки. Для каждой функции или условия принятия, команда облачной платформы завершает задачи разработки до прохождения теста или зеленого теста.

Цель TDD заключается в том, чтобы улучшить дизайн, а не создать набор тестов. Тесты являются ценным артефактом для завершения процесса.

Определение завершения

Успех может быть субъективной мерой, которая предоставляет команде облачной платформы мало практических сведений во время разработки или рефакторинга зоны посадки. Отсутствие ясности может привести к пропущенным ожиданиям и уязвимостям в облачной среде. Прежде чем команда облачной платформы рефакторирует или расширяет все целевые зоны, они должны искать ясность в отношении определения готового (DoD) для каждой целевой зоны.

DoD — это простое соглашение между командой облачной платформы и другими затронутыми командами, определяющими ожидаемые функции, добавляемые в целевую зону разработки. Часто DoD представляет собой контрольный список, согласованный с краткосрочным планом внедрения облачных технологий.

По мере того, как команды принимают на себя больше рабочих процессов и облачных возможностей, Министерство обороны США и критерии принятия становятся более сложными. В зрелых процессах ожидаемые функции имеют собственные критерии принятия, чтобы обеспечить более четкость. Когда функции с добавленной стоимостью соответствуют критериям принятия, целевая зона достаточно настроена, чтобы обеспечить успех текущей волны внедрения или релиза.

Простой пример Министерства обороны (DoD)

Для изначальных усилий по миграции Министерство обороны может оказаться слишком простым. Следующий пример — это простой «DoD»:

Начальная посадочная зона будет размещать 10 рабочих нагрузок для целей начального обучения. Эти рабочие нагрузки не критически важны для бизнеса и не имеют доступа к конфиденциальным данным. В будущем эти рабочие нагрузки, вероятно, будут внедрены в производство, но их критичность и чувствительность не изменятся.

Для поддержки этих рабочих нагрузок команда внедрения облака должна соответствовать следующим критериям:

  • Сегментация сети для соответствия предлагаемому проекту сети. Эта среда должна быть сетью периметра с доступом к общедоступному Интернету.
  • Доступ к вычислительным, хранилищным и сетевым ресурсам для размещения рабочих нагрузок в соответствии с исследованием цифрового имущества.
  • Схема именования и тегов для простоты использования.
  • Во время внедрения временный доступ для команды внедрения облака для изменения конфигураций служб.
  • До выхода в эксплуатацию интеграция с поставщиком услуг управления корпоративной идентичностью для управления текущими учетными записями и доступом к управлению операциями. В то время доступ команды по внедрению облака должен быть отменен.

Последний пункт не является характеристикой или критерием принятия, но служит индикатором того, что потребуется больше расширений, и это следует изучать вместе с другими командами на раннем этапе.

Более сложные примеры DoD

Методология управления в Cloud Adoption Framework предоставляет повествование о естественной зрелости команды управления. Внедренные в это путешествие являются несколькими примерами условий doD и принятия в виде инструкций политики.

Приведенные выше примеры — это базовые образцы, которые помогут вам разработать DoD для ваших посадочных зон.

Средства и функции Azure для поддержки TDD посадочной зоны

На следующей схеме показаны доступные средства разработки на основе тестов в Azure:

Диаграмма, показывающая доступные инструменты разработки с применением тестирования в 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 Policy может применить критерии тестирования, чтобы избежать изменений кода, которые привели бы к сбоям тестов в будущих релизах.

    Проектирование и проверка рабочих процессов Политики Azure в качестве кода в рамках подхода TDD.

  • Azure Resource Graph предоставляет язык запросов для создания тестов, основанных на данных о активах, развернутых в зоне размещения. Далее в плане внедрения этот инструмент также может определить сложные тесты на основе взаимодействия между ресурсами рабочей нагрузки и базовой облачной средой.

    Resource Graph включает расширенные примеры запросов, которые можно использовать для понимания того, как нагрузки развертываются в зоне приземления для сложных сценариев тестирования.

В зависимости от предпочтительного подхода можно также использовать следующие средства:

Дальнейшие действия