Devops pipeline что это

Что такое Azure Pipelines?

Azure Pipelines автоматически выполняет сборку и тестирует проекты кода. Она поддерживает все основные языки и типы проектов и объединяет непрерывную интеграцию, непрерывную поставку и непрерывное тестирование для сборки, тестирования и доставки кода в любое место назначения.

Непрерывная интеграция

Непрерывная интеграция (CI) — это практика, используемая командами разработчиков для автоматизации, объединения и тестирования кода. CI помогает перехватывать ошибки на ранних этапах цикла разработки, что делает их менее затратными на исправление. Автоматические тесты выполняются в рамках процесса CI для обеспечения качества. Системы CI создают артефакты и используют их для выпуска процессов для частых развертываний.

Служба сборки в Azure DevOps Server помогает настроить ci для приложений и управлять ими.

Непрерывная поставка

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

Непрерывное тестирование

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

• Поддерживайте качество и находите проблемы по мере развития. Непрерывное тестирование с помощью Azure DevOps Server гарантирует, что приложение по-прежнему работает после каждого проверка и сборки, что позволяет находить проблемы раньше, автоматически запуская тесты при каждой сборке.
• Используйте любой тип теста и любую платформу тестирования. Выберите предпочитаемые технологии и платформы тестирования.
• Просмотр полнофункционированных аналитических сведений и отчетов. После завершения сборки просмотрите результаты теста, чтобы устранить любые проблемы. Отчеты о сборках с действиями позволяют мгновенно узнать, становятся ли ваши сборки более здоровыми. Но речь не только о скорости — подробные и настраиваемые результаты теста измеряют качество вашего приложения.

Системы управления версиями

Azure Pipelines требует, чтобы исходный код был в системе управления версиями. Azure DevOps поддерживает две формы управления версиями: Git и Azure Repos. Все изменения, которые вы отправляете в репозиторий системы управления версиями, автоматически создаются и проверяются.

Языки и приложения

Вы можете создавать, тестировать и развертывать приложения Node.js, Python, Java, PHP, Ruby, C#, C++, Go, XCode, .NET, Android и iOS. Параллельное выполнение этих приложений в Linux, macOS и Windows.

Azure DevOps предлагает задачи для создания и тестирования приложений .NET, Java, Node, Android, Xcode и C++. Аналогичным образом существуют задачи для выполнения тестов с использованием множества платформ и служб тестирования. Вы также можете выполнять сценарии командной строки, PowerShell или оболочки в службе автоматизации.

Цели развертывания

Используйте Azure Pipelines для развертывания кода в нескольких целевых объектах. Целевые объекты включают виртуальные машины, среды, контейнеры, локальные и облачные платформы или службы PaaS. Вы также можете опубликовать мобильное приложение в магазине.

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

Форматы пакетов

Для создания пакетов, которые могут использоваться другими пользователями, можно опубликовать пакеты NuGet, npm или Maven во встроенном репозитории управления пакетами в Azure Pipelines. Вы также можете использовать любой другой репозиторий управления пакетами по своему усмотрению.

Что нужно для использования Azure Pipelines?

Чтобы использовать Azure Pipelines, выполните следующие задачи:

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

• Скачайте агент сборки и установите его на сервере сборки.

Цены на Azure DevOps

Azure DevOps Services

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

Дополнительные сведения см. в статье Что такое общедоступный проект. Если вы используете частные проекты, вы можете выполнять до 1800 минут (30 часов) заданий конвейера бесплатно каждый месяц.

Azure DevOps Server

С пятью или менее активными пользователями Azure DevOps Express является бесплатным, простым в настройке и устанавливается в клиентских и серверных операционных системах. Он поддерживает все те же функции, что и Azure DevOps Server 2019.

Дополнительные сведения см. в разделе Цены на Azure DevOps Server.

Зачем использовать Azure Pipelines?

Azure Pipelines предоставляет быстрый, простой и безопасный способ автоматизации создания проектов с помощью согласованного и качественного кода, который легко доступен пользователям.

Используйте Azure Pipelines для поддержки следующих сценариев:

• Работает с любым языком или платформой
• Одновременное развертывание в разных типах целевых объектов
• Интеграция с развертываниями Azure
• Сборки на компьютерах Windows, Linux или Mac
• Интеграция с GitHub
• Работает с проектами с открытым кодом

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

Похожие статьи

• Регистрация в Azure Pipelines
• Create your first pipeline (Создание первого конвейера)
• Настройка конвейера

CI/CD и еще один CD. Разбираемся в терминологии pipelines в контексте автоматизации тестирования

В IT индустрии используется большое разнообразие инженерных культур и практик, таких как Agile, бережливое производство (lean software development), DevOps. Все они так или иначе нацелены на бесперебойную доставку ценности за счет повторяемых коротких итераций. Неотъемлемой частью такого подхода является конвейерный подход или по-английски – pipelines. Подразумевается, что в идеальном мире разработчик заливает код на сервер и дальше происходит магия, состоящая из автоматизированных этапов сборки проекта, контроля качества кода, запуска тестов и сбора метрики. На рынке существует большое количество платных и бесплатных инструментов для настройки такого процесса, который мы называем “процессом непрерывной интеграции” или CI/CD (Jenkins, GitLab CI, Teamcity и д.р. ). Однако для построения действительно зрелого процесса недостаточно просто установить инструмент. За каждым этапом конвейера стоит сложная логика того, что должно быть запущено, на каких вычислительных ресурсах и как эти ресурсы используются.

На собеседовании кандидаты очень часто гордо говорят, что знают CI/CD. Но знать можно по-разному. Одно дело нажимать кнопку запуска и смотреть, какой цвет получился: красный или зеленый. И совсем другое дело настраивать весь флоу от и до самостоятельно, чем обычно и занимаются DevOps инженеры. Для проверки глубины знаний я задаю базовый вопрос, на который очень редко получаю ответ: “А в чем разница между CI и CD ?”. Далее я хочу поделиться своим пониманием отличий CI от CD и от еще одного CD на примере запуска автотестов. Заранее предупрежу, что мое видение может частично отличаться от вашего. Ведь у всех нас немного разный опыт, разные проекты и источники для изучения, которые могут расходиться. Главное, что какое-то видение у вас есть!

Коротко про пирамиду тестирования

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

Фактически во всех модификациях пирамиды эти тесты лежат в основании. Они характеризуются низкой стоимостью и высокой скоростью запуска. Unit тесты подразумевают изолированное тестирование частей кода (методов и функций) и чаще всего выполняются разработчиками. Не требуют отдельного тестового стенда.

• Интеграционные / компонентные тесты

Самый нестандартизированный уровень, так как он сильно зависит от проекта и архитектуры разрабатываемой системы. Может дробиться на различные подуровни. Выделяется отдельный компонент системы (может быть как UI component так и API endpoint) и тестируется в изоляции от другого компонента и базы данных. Как и в случае с unit тестированием отдельный тестовый стенд не требуется, а все зависимости мокируются, что также значительно удешевляет и ускоряет тесты. Данный уровень может покрываться как разработчиками, так и тестировщиками.

Самый востребованный уровень, так как тестирование происходит с точки зрения пользователя. Больше никаких изоляций компонент и программных частей. Все происходит на тестовом стенде с полноценной базой данных. В большинстве случаев выполняется тестировщиками и ими же автоматизируется, например одним из самых популярных инструментов – Selenium. Это самый дорогой уровень, так как требует больше времени на прохождение тестов и ресурсов на поддержание тестового стенда.

CI — Continuous Integration

Непрерывная интеграция – это только самый начальный этап нашего pipeline. Здесь подразумевается именно интеграция нового кода разработчика с уже существующим кодом, находящимся у нас в репозитории. При отправке кода на сервер запускаются быстрые unit тесты и статические анализаторы кода, проверяющие, например, соответствие установленным стандартам кодирования. Также на этом этапе могут запускаться интеграционные и компонентные тесты, если они написаны изолированно, поскольку тестовый стенд не требуется. Так как этот этап быстр в прохождении (речь идет о минутах) и прост в установке, то довольно часто разработчики могут настроить его без привлечения DevOps.

CD — Continuous Delivery

Непрерывная доставка выводит наш pipeline на совершенно другой уровень. Для начала мы должны собрать наше приложение. В случае Web и Backend мы выкатываем изменения на тестовый стенд. А для мобильных приложений необходимо собрать билды. Только после этого можно переходить к запуску e2e тестов для Web / Mobile / API. Как вы видите, здесь понадобится огромное количество дополнительных компонентов: сервер базы данных, сервера для тестового стенда, механизм для развертывания кода, браузеры и эмуляторы для запуска тестов, механизм балансировки нагрузки. Все это требует большой нагрузки на CPU и память, а, значит, и дополнительные затраты на поддержку. Именно тут необходимо понимание DevOps технологий.

Еще один CD — Continuous Deployment

Вишенкой на торте является этап непрерывного развертывания. Его часто путают с непрерывной доставкой, так как у них одинаковая аббревиатура – CD. Именно этот этап делает наш pipeline действительно непрерывным. Во многих организациях я видел в основном предыдущий этап непрерывной доставки, когда тесты запускаются не тестовом стенде, а дальше тестировщики что-то проверяют руками или release-manager дает разрешение на влитие в основную ветку разработки (master) и сам релиз. В таком случае ни о какой непрерывности речи не идет. Непрерывное развертывание подразумевает автоматический релиз нашего кода в production, если все тесты на предыдущих этапах прошли успешно. В дополнение к этому собираются метрики продукта и сравниваются с предыдущими показателями.

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

Заключение

Мы рассмотрели 3 этапа построения pipeline и обсудили, какие тесты необходимо запускать на каждом из этих этапов. Если у вас есть опыт в использовании и построении CI / CD / CD, буду рад увидеть ваши варианты в комментариях.

Также хочу порекомендовать бесплатные уроки от моих коллег из OTUS по темам:

• Методы тестирования
• Реализация подхода DDT в автотестах.

Непрерывная интеграция и доставка (СI/CD pipeline)

В бизнесе критической стала бесперебойность и скорость работы. Непрерывные тесты и непрерывная доставка кода увеличивают скорость и качество продукта. Поставив код на слаженный конвейер, бизнес решает проблему затянутых релизов и оттягивание запуска продукта. Continuous Integration & Continuous Delivery (CI/CD) («непрерывная интеграция и доставка»), становится спасательным кругом. Концепция разрешает делать слияние копий частей кода в ветку несколько раз в день. На каждом этапе происходит автоматическое тестирование, по CI/CD pipeline код развертывается в готовый продукт. Принцип похож на конвейер, который оптимизирует процесс доставки кода, повышая качество.

CI/CD для чайников

Рассказываем про CI/CD pipeline «для чайников» – как работает и как вписывается в DevOps-методологию. CI/CD системы нужны для регулярной автоматизированной сборки кода. Это делается для моментального выявления ошибок и устранения дефектов в итерациях. CI/CD pipeline делает возможной непрерывность итераций и снижает трудоемкость в случае раннего выявления дефекта.

Говоря про CI/CD pipeline «для чайников», уточняем, что метод лежит в основе идеологии DevOps. Что касается автоматического тестирования, здесь процесс CI/CD соответствует базовым принципам Agile. Что такое CI/CD в рамках DevOps? Это практический инструмент реализации стратегии DevOps с помощью программных платформ.

Возможно, вы задались вопросом CI/CD pipeline – что это? В контексте софтверной отрасли под pipeline подразумеваем «конвейер», по которому доставляется код. Как работают CI/CD пайплайны? С помощью каких CI/CD tools реализуется работа конвейера. Хостинги репозиториев, такие как Bitbucket CI/CD, Github CI/CD, используются в качестве пайплайна доставки кода. Есть и другие CI/CD системы, например, CI/CD Jenkins, облачный сервис CI/CD AWS, Azure DevOps CI/CD. У каждого из этих инструментов есть преимущества. Команды сами выбирают, с чем удобнее работать – нет жестких рекомендаций по конкретным тулзам. По теме CI/CD Habr выдает тонны статей, попробуем собрать общую информацию про CI/CD tools ниже.

CI/CD инструменты

Разобрались с вопросом CI/CD что это и как эта концепция влияет на доставку кода. Теперь переходим непосредственно к инструментам. Как уже говорили, есть системы, которые описывают процессы конвейера непрерывной доставки.

В автоматическом деплое приложений часто используется инструмент автоматизации CI/CD Jenkins, для управления пайплайном. Преимущество CI/CD Jenkins – бесплатные плагины, которые регулярно обновляются. Например:

• Jenkins job builder, используется для описания задач.
• Локальный DSL Plugin для описания задач пайплайна.
• Gitlab и Gitlab CI/CD – внутри CI на Go и агенты для сборки и деплоймента.
• GitHub Pull Request Builder – автоматизирует прослеживание pull-requests Github. Также объединяет изменения, запускает сборку, делает анализ и выдает статус реквеста.

Сервер непрерывной интеграции CI/CD Teamcity применяется для конфигурации сборки кода и отслеживания коммитов. После этого ПО запускает билд и unit-тесты. В режиме реального времени отслеживаем сбои тестов, компиляции и проверять код. Процессы CI/CD превращаем в шаблоны и создавать конфигурации сборки.

Благодаря контейнеризации на Docker, CI/CD получает доступ к репозиторию образов и легко разворачивает приложения. С Docker CI/CD покрывает работу в разных средах, а деплой можно делать в одном окружении. А это немалый плюс, если настройка CI/CD сделана корректно.

Gitlab CI/CD настройка

Gitlab – SAAS сервис для размещения Git-репозиториев, отслеживания дефектов и составления wiki на markdown. Gitlab работает на разных сервисах – Docker, BitBucket Pipelines, GoCD Jenkins, Docker, Heroku CI, AWS CodeBuild и других. Рассказываем, с чего начинается Gitlab CI/CD настройка на Docker и Kubernetes.

Начнем с Gitlab CI/CD Docker. С Docker настраиваем непрерывную интеграцию, используя докер-образы. Для начала проверяем доступ на сервер Git, наличие SSL-сертификата и SSH-ключа. Создаем master-slave серверы, и сервер для сборки контейнеров и их запуска. Образ Docker – для подготовки Runner, Manager и Node серверов. Строим secure connection между Runner-сервером и Docker.

Для конфигурирования Gitlab CI/CD Kubernetes нужно настроить домен и SSL-сертификат. После создаем и активируем GitLab-репозиторий. Логинимся и подготавливаем к запуску проект. В нем будет размещен код, проходящий через Kubernetes CI/CD pipeline для сборки и развертывания. Это базовые подготовительные этапы. Как подробно настраивать CI/CD инструменты – тема для отдельной статьи.

В проектах Gitlab CI/CD настройка системы снижает риски на каждом из этапов. Логические тесты разработчиков, целостность данных от QA, удобство использования – на бизнес-аналитиках и Product Owners. DevOps, в свою очередь, несут ответственность за эту конвейерную карусель.

Руководство по Непрерывная интеграция шаблонов Resource Manager с Azure Pipelines

В предыдущем учебнике развертывался связанный шаблон. В этом учебнике описано, как использовать Azure Pipelines для непрерывного создания и развертывания проектов шаблонов Resource Manager.

Azure DevOps предоставляет сервисы для разработчиков, которые помогают рабочим группам планировать работу, совместно разрабатывать код, а также создавать и развертывать приложения. Разработчики могут работать в облаке с помощью Azure DevOps Services. Azure DevOps предоставляет интегрированный набор функций, доступ к которым можно получить через веб-браузер или клиент IDE. Azure Pipelines является одной из этих функций. Azure Pipelines — это полнофункциональная служба непрерывной интеграции (CI) и непрерывной доставки (CD). Она работает с вашим основным провайдером Git и может развертываться в большинстве крупных облачных служб. Затем вы можете автоматизировать сборку, тестирование и развертывание своего кода в Microsoft Azure, Google Cloud Platform или Amazon Web Services.

Выберите имя проекта. При работе с руководством замените любой из ARMPipelineProj именем проекта. Это имя проекта используется для создания имен ресурсов. Одним из ресурсов является учетная запись хранения. Имя учетной записи хранения должно содержать от 3 до 24 символов и состоять только из цифр и букв нижнего регистра. Имя должно быть уникальным. В шаблоне имя учетной записи хранения — это имя проекта с добавлением store, которое должно содержать от 3 до 11 символов. Поэтому имя проекта должно соответствовать требованиям к имени учетной записи хранения и быть длиной менее 11 символов.

В рамках этого руководства рассматриваются следующие задачи:

• Подготовка репозитория GitHub
• Создание проекта Azure DevOps.
• Создание конвейера Azure
• Проверка развертывания конвейера
• Обновление шаблона и повторное развертывание
• Очистка ресурсов

Если у вас еще нет подписки Azure, создайте бесплатную учетную запись Azure, прежде чем начинать работу.

Предварительные требования

Для работы с этой статьей необходимо иметь следующее.

• Учетная запись GitHub — где ее можно использовать для репозитория шаблонов. Если у вас ее нет, вы можете создать ее бесплатно. Подробнее об использовании репозиториев GitHub см. в статье Сборка репозиториев GitHub.
• Установка Git. В этой инструкции руководства используется Git Bash или Git Shell. Инструкции см. в разделе Установка Git.
• Организация Azure DevOps. Если у вас ее нет, вы можете создать ее бесплатно. См. статью Создание организации или коллекции проектов.
• (Необязательно) Visual Studio Code с расширением средств Resource Manager. См. Краткое руководство. Создание шаблонов ARM с помощью Visual Studio Code.

Подготовка репозитория GitHub

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

Создание репозитория GitHub

Если у вас нет учетной записи GitHub, см. раздел Предварительные требования.

1. Вход в GitHub.
2. Выберите в правом верхнем углу изображение своей учетной записи, а затем выберите Ваши репозитории.
3. Нажмите зеленую кнопку Новый.
4. В поле Имя репозитория введите имя репозитория. Например, ARMPipeline-repo. Не забудьте заменить любой из ARMPipeline именем проекта. Вы можете выбрать общедоступный или частный для просмотра этого руководства. Затем выберите Создать репозиторий.
5. Введите URL-адрес. URL-адрес репозитория имеет следующий формат: https://github.com/[YourAccountName]/[YourRepositoryName] .

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

Клонирование репозитория

1. Откройте Git Shell или Git Bash. См. раздел Предварительные требования.
2. Убедитесь, что вашей текущей папкой является GitHub.
3. Выполните следующую команду:

git clone https://github.com/[YourAccountName]/[YourGitHubRepositoryName] cd [YourGitHubRepositoryName] mkdir create_web_app cd create_web_app pwd 

Папка create_web_app — это папка, в которой хранится шаблон. С помощью команды pwd отображается путь к папке. Путь — это расположение, в котором будет сохраняться шаблон при выполнении следующей процедуры.

Загрузите шаблон быстрого запуска

Вместо создания шаблонов можно скачать шаблоны и сохранить их в папке create_web_app .

• Основной шаблон: https://raw.githubusercontent.com/Azure/azure-docs-json-samples/master/get-started-deployment/linked-template/azuredeploy.json.
• Связанный шаблон: https://raw.githubusercontent.com/Azure/azure-docs-json-samples/master/get-started-deployment/linked-template/linkedStorageAccount.json.

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

Отправьте шаблон в удаленный репозиторий

Файл azuredeploy.json добавлен в локальный репозиторий. Затем загрузите шаблон в удаленный репозиторий.

1. Откройте Git Shell или Git Bash, если он не открыт.
2. Перейдите в папку create_web_app в локальном репозитории.
3. Убедитесь, что файл azuredeploy.json находится в папке.
4. Выполните следующую команду:

git add . git commit -m "Add web app templates." git push origin main 

Вы создали репозиторий GitHub и загрузили в него шаблоны.

Создание проекта DevOps

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

1. Вход в Azure DevOps.
2. Выберите организацию DevOps слева, а затем выберите Новый проект. Если у вас нет проектов, страница создания проекта откроется автоматически.
3. Введите следующие значения.
   • Имя проекта. Введите имя проекта. Вы можете использовать имя проекта, которое вы выбрали в самом начале руководства.
   • Видимость: выберите Частный.

Для других свойств используйте значения по умолчанию.

Создайте подключение к службе, которое используется для развертывания проектов в Azure.

1. Выберите Параметры проекта в нижней части левого меню.
2. Выберите Подключения к службе в Pipelines.
3. Щелкните Создать подключение к службе, затем — Azure Resource Manager и нажмите кнопку Далее.
4. Выберите Субъект-служба (автоматически) и нажмите кнопку Далее.
5. Введите следующие значения.
   • Уровень области: выбор Подписки.
   • Подписка: выберите свою подписку.
   • Группа ресурсов. Оставьте пустым.
   • Имя подключения: ввод имени подключения. Например, ARMPipeline-conn. Запишите это имя, оно вам понадобится при создании конвейера.
   • Предоставить разрешение на доступ для всех конвейеров (выбрано)
6. Щелкните Сохранить.

Создание конвейера

До этого момента мы выполнили следующие задачи. Если вы пропустили предыдущие разделы, потому что уже работали с GitHub и DevOps, перед продолжением необходимо выполнить следующие задачи.

• Создайте репозиторий GitHub и сохраните шаблоны в папке create_web_app в репозитории.
• Создайте проект DevOps и создайте подключение службы Azure Resource Manager.

Чтобы создать конвейер с шагом для развертывания шаблона:

1. Выберите Pipelines в меню слева.
2. Выберите Создать конвейер.
3. На вкладке Подключить выберите GitHub. Если потребуется, введите учетные данные GitHub, а затем следуйте инструкциям. Если вы видите следующий экран, выберите Выбрать только репозитории и убедитесь, что ваш репозиторий находится в списке, прежде чем выбрать Утвердить и установить.
4. На вкладке Выбрать выберите свой репозиторий. По умолчанию используется имя [YourAccountName]/[YourGitHubRepositoryName] .
5. На вкладке Настроить выберите Простейший конвейер. Он отобразит файл конвейера azure-pipelines.ymlв два этапа с помощью сценария.
6. Удалите два шага скрипта из YML-файла.
7. Переместите курсор в строку после steps: .
8. Щелкните Показать помощника в правой части экрана, чтобы открыть область Задачи.
9. Выберите ARM template deployment (Развертывание шаблона Resource Manager).
10. Введите следующие значения.
    • deploymentScope: Щелкните Группа ресурсов. Дополнительные сведения об областях см. в разделе Области развертывания.
    • Azure Resource Manager connection (Подключение Azure Resource Manager): выберите имя подключения службы, созданного ранее.
    • Подписка: укажите идентификатор целевой подписки.
    • Action (Действие). Выберите значение 1, но учтите, что действие Create Or Update Resource Group (Создание и изменение группы ресурсов) выполняет 2 действия. создает группу ресурсов, если указано новое имя группы ресурсов; 2. развертывает указанный шаблон;
    • Группа ресурсов. Введите имя новой группы ресурсов. Например, ARMPipeline-rg.
    • Расположение. Выберите расположение группы ресурсов, например Центральная часть США.
    • Расположение шаблона: выберите URL-адрес файла, чтобы в рамках задачи выполнялся поиск файла шаблона по URL-адресу. Так как relativePath применяется в основном шаблоне и relativePath поддерживают только развертывания на основе URI, здесь нужно использовать URL-адрес.
    • Ссылка на шаблон: введите URL-адрес, полученный при работе с последней частью раздела Подготовка репозитория GitHub. Он начинается с https://raw.githubusercontent.com .
    • Ссылка на параметры шаблона: оставьте это поле пустым. Вы укажете значения параметров в поле Переопределить параметры шаблона.
    • Переопределить параметры шаблона: введите -projectName [EnterAProjectName] .
    • Deployment mode (Режим развертывания): выберите значение Добавочный.
    • Deployment name (Имя развертывания): введите DeployPipelineTemplate. Чтобы можно было увидеть Имя развертывания, нажмите кнопкуAdvanced (Дополнительно).

Выберите Добавить. Дополнительные сведения о задаче см. в статьях Azure Resource Group Deployment task (Задача развертывания группы ресурсов Azure) и Azure Resource Manager template deployment task (Задача развертывания шаблона Azure Resource Manager). YML-файл должен иметь следующий вид:

Выберите Сохранить и запустить.

В области Save and run (Сохранить и запустить) щелкните Save and run (Сохранить и запустить) еще раз. Копия файла YAML сохраняется в подключенном хранилище. Вы можете увидеть файл YAML, перейдя в свой репозиторий.

Убедитесь, что конвейер успешно выполнен.

Проверка развертывания

1. Войдите на портал Azure.
2. Откройте группу ресурсов. Имя — это то, что вы указали в файле YAML конвейера. Вы ознакомитесь с одной созданной учетной записью хранения. Имя учетной записи хранения начинается с store.
3. Выберите имя учетной записи хранения, чтобы открыть ее.
4. Выберите Свойства. В поле Репликация должно быть указано Локально избыточное хранилище (LRS) .

Обновление и повторное развертывание

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

1. Откройте linkedStorageAccount.json из локального репозитория в Visual Studio Code или любом текстовом редакторе.
2. Обновите defaultValue из storageAccountType до Standard_GRS. Экран должен выглядеть так:
3. Сохраните изменения.
4. Отправьте изменения в удаленный репозиторий, выполнив следующие команды из Git Bash/Shell.

git pull origin main git add . git commit -m "Update the storage account type." git push origin main 

Чтобы проверить изменения, можно проверить свойство «Репликация» учетной записи хранения. См. раздел Проверка развертывания.

Очистка ресурсов

Если ресурсы Azure больше не нужны, их можно удалить. Для этого необходимо удалить группу ресурсов.

1. На портале Azure в меню слева выберите Группа ресурсов.
2. В поле Фильтровать по имени введите имя группы ресурсов.
3. Выберите имя группы ресурсов.
4. В главном меню выберите Удалить группу ресурсов.

Кроме того, также можно удалить репозиторий GitHub и проект DevOps Azure.

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

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