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

Базовая архитектура 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. pipeline PR - Запрос на вытягивание (PR) в Azure Repos Git активирует pipeline PR. Этот конвейер выполняет быстрые проверки качества. Эти проверки должны включать:

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

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

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

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

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

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

  6. мониторинг . Azure Monitor собирает данные о наблюдаемости, такие как журналы и метрики, чтобы оператор мог анализировать данные о работоспособности, производительности и использовании. Application Insights собирает все данные мониторинга, относящиеся к приложениям, например, трассировки. 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. Используйте эти данные для мониторинга приложения, настройки оповещений, панелей мониторинга и выполнения анализа первопричин сбоев.

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

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

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

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

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

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

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

  • репозитории GitHub могут быть заменены как репозитории кода. Azure Pipelines легко интегрируется с репозиториями GitHub.

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

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

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

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

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

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

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

Сведения о сценарии

Использование проверенных методик 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), чтобы определить инфраструктуру и развернуть ее в конвейерах.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ознакомьтесь со следующими ресурсами, чтобы узнать больше о CI/CD и Azure DevOps: