Базовая архитектура CI/CD с помощью Azure Pipelines

  • Статья

В этой статье описывается высокоуровневый рабочий процесс DevOps для развертывания изменений приложения в промежуточных и рабочих средах в Azure. Решение использует методики непрерывной интеграции и непрерывного развертывания (CI/CD) с Azure Pipelines.

Внимание

В этой статье рассматривается общая архитектура CI/CD с помощью Azure Pipelines. Он не предназначен для покрытия особенностей развертывания в разных средах, таких как службы приложение Azure, Виртуальные машины и Платформа Azure Power Platform. Особенности платформы развертывания рассматриваются в отдельных статьях.

Архитектура

Схема архитектуры конвейера CI/CD с помощью Azure Pipelines.

Скачайте файл Visio для этой архитектуры.

Примечание.

Хотя в этой статье рассматриваются изменения CI/CD для изменений приложений, Azure Pipelines также можно использовать для создания конвейеров CI/CD для инфраструктуры в виде кода (IaC).

Поток данных

Данные передаются в сценарии следующим образом:

  1. Конвейер PR — запрос на вытягивание (PR) в Azure Repos Git активирует конвейер PR. Этот конвейер выполняет быстрые проверка. Эти проверка должны включать:

    • Создание кода, требующего извлечения зависимостей из системы управления зависимостями.
    • Использование средств для анализа кода, таких как статический анализ кода, подкладка и сканирование безопасности
    • Модульные тесты

    Если любой из проверка завершается сбоем, выполнение конвейера завершится, и разработчику придется внести необходимые изменения. Если все проверка передаются, конвейер должен требовать проверки pr. Если проверка pr завершается ошибкой, конвейер заканчивается, и разработчику придется внести необходимые изменения. Если все проверка и проверки PR проходят, то pr-запрос будет успешно слиянием.

  2. Конвейер CI— слияние с Azure Repos Git активирует конвейер CI. Этот конвейер выполняет те же проверка, что и конвейер PR с некоторыми важными дополнениями. Конвейер CI выполняет тесты интеграции. Эти тесты интеграции не должны требовать развертывания решения, так как артефакты сборки еще не созданы. Если для тестов интеграции требуются секреты, конвейер получает эти секреты из Azure Key Vault. Если какой-либо из проверка завершается ошибкой, конвейер заканчивается, и разработчику придется внести необходимые изменения. Результат успешного выполнения этого конвейера — создание и публикация артефактов сборки

  3. Триггер конвейера CD — публикация артефактов активирует конвейер CD.

  4. Выпуск CD для промежуточного хранения. Конвейер CD загружает артефакты сборки, созданные в конвейере CI, и развертывает решение в промежуточной среде. Затем конвейер выполняет тесты принятия в промежуточной среде для проверки развертывания. Если какой-либо тест принятия завершается сбоем, конвейер завершается, и разработчику придется внести необходимые изменения. Если тесты выполнены успешно, задача проверки вручную может быть реализована, чтобы требовать от пользователя или группы проверить развертывание и возобновить конвейер.

  5. Выпуск CD в рабочую среду. Если вмешательство вручную возобновляется или не реализовано ручного вмешательства, конвейер освобождает решение в рабочую среду. Конвейер должен выполнять тесты дыма в рабочей среде, чтобы убедиться, что выпуск работает должным образом. Если шаг вмешательства вручную приводит к отмене, выпуск завершается сбоем или сбоем тестов дыма, выпуск откатывается, конвейер заканчивается, и разработчику придется внести необходимые изменения.

  6. Мониторинг — Azure Monitor собирает данные о наблюдаемости, такие как журналы и метрики, чтобы оператор может анализировать данные о работоспособности, производительности и использовании. Приложение Аналитика собирает все данные мониторинга для конкретных приложений, такие как трассировки. Azure Log Analytics используется для хранения всех данных.

Компоненты

  • Репозиторий Azure Repos Git служит в качестве репозитория кода, который предоставляет управление версиями и платформу для совместных проектов.

  • Azure Pipelines предоставляет способ создания, тестирования, пакета и выпуска кода приложения и инфраструктуры. В этом примере есть три отдельных конвейера со следующими обязанностями:

    • Конвейеры PR проверяют код перед тем, как разрешить PR объединяться с помощью подстроки, сборки и модульного тестирования.
    • Конвейеры CI выполняются после объединения кода. Они выполняют ту же проверку, что и конвейеры PR, но добавляют тестирование интеграции и публикуют артефакты сборки, если все успешно.
    • Конвейеры CD развертывают артефакты сборки, выполняют тесты принятия и выпускаются в рабочую среду.

  • Веб-каналы артефактов Azure позволяют управлять пакетами программного обеспечения, такими как Maven, npm и NuGet. Веб-каналы артефактов позволяют управлять жизненным циклом пакетов, включая управление версиями, продвижение и выход из эксплуатации пакетов. Это поможет вам убедиться, что ваша команда использует последние и самые безопасные версии пакетов.

  • Key Vault предоставляет способ управления безопасными данными для решения, включая секреты, ключи шифрования и сертификаты. В этой архитектуре он используется для хранения секретов приложений. Эти секреты доступны через конвейер. Доступ к секретам можно получить с помощью Azure Pipelines с помощью задачи Key Vault или связывания секретов из Key Vault.

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

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

  • Рабочая область Log Analytics предоставляет центральное расположение, в котором можно хранить, запрашивать и анализировать данные из нескольких источников, включая ресурсы Azure, приложения и службы.

Альтернативные варианты

Хотя эта статья посвящена Azure Pipelines, вы можете рассмотреть следующие варианты:

  • Azure DevOps Server (ранее известный как Team Foundation Server) можно использовать в качестве локальной замены.

  • Jenkins — это средство открытый код, используемое для автоматизации сборок и развертываний.

  • GitHub Actions позволяет автоматизировать рабочие процессы CI/CD непосредственно из GitHub.

  • Репозитории GitHub можно заменить в качестве репозитория кода. Azure Pipelines легко интегрируется с репозиториями GitHub.

В этой статье рассматриваются общие методики CI/CD с помощью Azure Pipelines. Ниже приведены некоторые вычислительные среды, в которых можно рассмотреть возможность развертывания:

  • Служба приложений — это служба на основе HTTP для размещения веб-приложений, REST API и мобильных серверных серверов. Вы можете разрабатывать на выбранном языке, а также запускать и масштабировать приложения с легкостью в средах под управлением Windows и Linux. веб-приложения поддерживает слоты развертывания, такие как промежуточная и рабочая среда. Вы можете развернуть приложение в промежуточном слоте и освободить его в рабочем слоте.

  • Azure Виртуальные машины обрабатывает рабочие нагрузки, требующие высокого уровня управления, или зависит от компонентов и служб ОС, которые недоступны для веб-приложения (например, windows GAC или COM).

  • Azure Power Platform — это коллекция облачных служб, которые позволяют пользователям создавать, развертывать и управлять приложениями без необходимости в инфраструктуре или техническом опыте.

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

  • Служба Azure Kubernetes (AKS) — это управляемый кластер Kubernetes в Azure. Kubernetes — это платформа оркестрации контейнеров открытый код.

  • Приложения контейнеров Azure позволяют запускать контейнерные приложения на бессерверной платформе.

Подробности сценария

Использование проверенных методик CI и CD для развертывания изменений приложения или инфраструктуры обеспечивает различные преимущества, включая:

  • Короткие циклы выпуска — автоматизированные процессы CI/CD позволяют быстрее развертывать методы вручную. Многие организации развертывают несколько раз в день.
  • Лучшее качество кода — качество шлюзов в конвейерах CI, таких как подкладка и модульное тестирование, приводит к повышению качества кода.
  • Снижение риска выпуска — надлежащие методики CI/CD значительно снижают риск выпуска новых функций. Развертывание можно протестировать до выпуска.
  • Повышенная производительность . Автоматизированная ci/CD освобождает разработчиков от работы с ручной интеграцией и развертываниями, чтобы они могли сосредоточиться на новых функциях.
  • Включение откатов . Хотя правильные методики CI/CD снижают количество ошибок или регрессий , которые выпускаются, они по-прежнему возникают. CI/CD может включить автоматический откат к более ранним выпускам.

Потенциальные варианты использования

Рассмотрим процессы Azure Pipelines и CI/CD для:

  • Ускорение жизненного цикла разработки и развертывания приложений.
  • Создание качества и согласованности в автоматизированном процессе сборки и выпуска.
  • Повышения стабильности и времени доступности приложения.

Рекомендации

Эти рекомендации реализуют основные принципы платформы Azure Well-Architected Framework, которая является набором руководящих принципов, которые можно использовать для улучшения качества рабочей нагрузки. Дополнительные сведения см. в статье Microsoft Azure Well-Architected Framework.

Эффективность работы

  • Рекомендуется реализовать инфраструктуру как код (IaC), чтобы определить инфраструктуру и развернуть ее в конвейерах.

  • Рассмотрите возможность использования одной из задач токенизации, доступных в Marketplace VSTS, в контексте часто относится к процессу, в котором конфиденциальная информация (например, ключи API, пароли или другие секреты) заменена маркерами или заполнителями во время развертывания или настройки.

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

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

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

  • Рекомендуется использовать отдельные ресурсы мониторинга для рабочей среды.

  • Рекомендуется использовать конвейеры YAML вместо классического интерфейса. Конвейеры YAML можно рассматривать как другой код. Конвейеры YAML можно проверка в систему управления версиями и управления версиями, например.

  • Рекомендуется использовать шаблоны YAML для повышения повторного использования и упрощения конвейеров. Например, конвейеры PR и CI похожи. Для обоих конвейеров можно использовать один параметризованный шаблон.

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

Оптимизация затрат

Оптимизация затрат заключается в поиске способов уменьшения ненужных расходов и повышения эффективности работы. Дополнительные сведения см. в разделе Обзор критерия "Оптимизация затрат".

Расчет стоимости Azure DevOps будет зависеть от количества пользователей в организации, которым требуется доступ, в дополнение к таким факторам, как количество параллельных требуемых выпусков и сборок, а также число тестовых пользователей. Дополнительные сведения см. Цены на Azure DevOps.

Калькулятор цен предоставляет оценку запуска Azure DevOps с 20 пользователями.

Azure DevOps оплачивается в расчете на каждого пользователя за месяц. В зависимости от необходимых параллельных конвейеров может потребоваться больше расходов, помимо дополнительных тестовых пользователей или базовых лицензий пользователей.

Безопасность

  • Учитывайте преимущества безопасности использования размещенных корпорацией Майкрософт агентов при выборе того, следует ли использовать размещенные корпорацией Майкрософт или локальные агенты.

  • Убедитесь, что все изменения в средах выполняются через конвейеры. Реализуйте элементы управления доступом на основе ролей (RBAC) в принципе наименьших привилегий, предотвращая доступ пользователей к средам.

  • Рассмотрите возможность интеграции шагов в Azure Pipelines для отслеживания зависимостей, управления лицензированием, сканирования уязвимостей и поддержания зависимостей в актуальном состоянии.

Следующие шаги

Для получения дополнительных сведений о CI/CD и Azure DevOps ознакомьтесь со следующими ресурсами.