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


Руководство по развертыванию сред в CI/CD с помощью GitHub и сред развертывания Azure

В этом руководстве описано, как интегрировать среды развертывания Azure в конвейер CI/CD. Вы можете использовать любой поставщик GitOps, поддерживающий CI/CD, например GitHub Actions, Azure Arc, GitLab или Jenkins.

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

Вы используете рабочий процесс, который включает три ветви: main, dev и test.

  • Основная ветка всегда считается продуктивной.
  • Вы создаете функциональные ветви из основной ветви .
  • Вы создаете пулл-реквесты для объединения функциональных веток в главную.

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

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

В этом руководстве описано, как:

  • Создание и настройка центра разработки
  • Создание хранилища ключей
  • Создание и настройка репозитория GitHub
  • Подключение каталога к центру разработки
  • Настройка идентификаторов развертывания
  • Настройка сред GitHub
  • Протестируйте конвейер CI/CD

Предпосылки

Продукт Требования
Лазурный подписка Azure.
— Разрешения владельца в подписке Azure.
- Azure CLI установлен.
Git учетная записьGitHub.
установлен - Git.

1. Создание и настройка центра разработки

В этом разделе описано, как создать центр разработки сред развертывания Azure и проект с тремя типами среды: dev, Testи Prod.

  • Тип среды Prod содержит единственную производственную среду.
  • Новая среда создается в dev для каждой ветви компонентов.
  • Новая среда создается в Test для каждого пул-реквеста.

1.1 Настройка Azure CLI

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

az login

Затем установите расширение Центра разработки Azure для Azure CLI:

az extension add --name devcenter --upgrade

Теперь, когда установлено текущее расширение, зарегистрируйте пространство имен Microsoft.DevCenter:

az provider register --namespace Microsoft.DevCenter

Подсказка

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

Получите идентификатор пользователя и задайте его в переменную среды для последующего выполнения:

MY_AZURE_ID=$(az ad signed-in-user show --query id -o tsv)

Получите идентификатор подписки для текущей подписки:

AZURE_SUBSCRIPTION_ID=$(az account show --query id --output tsv)

Получите идентификатор клиента для текущего клиента:

AZURE_TENANT_ID=$(az account show --query tenantId --output tsv)

Задайте следующие переменные среды:

LOCATION="eastus"
AZURE_RESOURCE_GROUP=<resourceGroupName>
AZURE_DEVCENTER=<devcenterName>
AZURE_PROJECT=<projectName>
AZURE_KEYVAULT=<keyVaultName>

Примечание.

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

Code: VaultAlreadyExists Message: The vault name 'mykeyvaultname' is already in use. Vault names are globally unique so it is possible that the name is already taken.

1.2. Создание центра разработки

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

Создайте группу ресурсов:

az group create \
  --name $AZURE_RESOURCE_GROUP \
  --location $LOCATION

Создайте центр разработки:

az devcenter admin devcenter create \
  --name $AZURE_DEVCENTER \
  --identity-type SystemAssigned \
  --resource-group $AZURE_RESOURCE_GROUP \
  --location $LOCATION

Предыдущая команда выводит JSON. Сохраните значения для id и identity.principalId в качестве переменных среды для последующего использования:

AZURE_DEVCENTER_ID=<id>
AZURE_DEVCENTER_PRINCIPAL_ID=<identity.principalId>

1.3. Назначьте роль владельца удостоверения центра разработки в рамках подписки

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

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

az role assignment create \
  --scope /subscriptions/$AZURE_SUBSCRIPTION_ID \
  --role Owner \
  --assignee-object-id $AZURE_DEVCENTER_PRINCIPAL_ID \
  --assignee-principal-type ServicePrincipal

1.4. Создание типов среды

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

Создайте три новых типа среды: Dev, Testи Prod:

az devcenter admin environment-type create \
  --name Dev \
  --resource-group $AZURE_RESOURCE_GROUP \
  --dev-center $AZURE_DEVCENTER
az devcenter admin environment-type create \
  --name Test \
  --resource-group $AZURE_RESOURCE_GROUP \
  --dev-center $AZURE_DEVCENTER
az devcenter admin environment-type create \
  --name Prod \
  --resource-group $AZURE_RESOURCE_GROUP \
  --dev-center $AZURE_DEVCENTER

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

проект — это точка доступа для команды разработчиков. Каждый проект связан с центром разработки.

Создайте проект:

az devcenter admin project create \
  --name $AZURE_PROJECT \
  --resource-group $AZURE_RESOURCE_GROUP \
  --location $LOCATION \
  --dev-center-id $AZURE_DEVCENTER_ID

Предыдущая команда выводит JSON. Сохраните значение id в качестве переменной среды для последующего использования:

AZURE_PROJECT_ID=<id>

Назначьте себе роль администратора проекта DevCenter в проекте:

az role assignment create \
  --scope "$AZURE_PROJECT_ID" \
  --role "DevCenter Project Admin" \
  --assignee-object-id $MY_AZURE_ID \
  --assignee-principal-type User

1.6. Создание типов среды проекта

На уровне проекта инженеры платформы указывают, какие типы среды подходят для команды разработчиков.

Создайте новый тип среды проекта для каждого типа среды, созданного в центре разработки:

az devcenter admin project-environment-type create \
  --name Dev \
  --roles "{\"b24988ac-6180-42a0-ab88-20f7382dd24c\":{}}" \
  --deployment-target-id /subscriptions/$AZURE_SUBSCRIPTION_ID \
  --resource-group $AZURE_RESOURCE_GROUP \
  --location $LOCATION \
  --project $AZURE_PROJECT \
  --identity-type SystemAssigned \
  --status Enabled
az devcenter admin project-environment-type create \
  --name Test \
  --roles "{\"b24988ac-6180-42a0-ab88-20f7382dd24c\":{}}" \
  --deployment-target-id /subscriptions/$AZURE_SUBSCRIPTION_ID \
  --resource-group $AZURE_RESOURCE_GROUP \
  --location $LOCATION \
  --project $AZURE_PROJECT \
  --identity-type SystemAssigned \
  --status Enabled
az devcenter admin project-environment-type create \
  --name Prod \
  --roles "{\"b24988ac-6180-42a0-ab88-20f7382dd24c\":{}}" \
  --deployment-target-id /subscriptions/$AZURE_SUBSCRIPTION_ID \
  --resource-group $AZURE_RESOURCE_GROUP \
  --location $LOCATION \
  --project $AZURE_PROJECT \
  --identity-type SystemAssigned \
  --status Enabled

2. Создание хранилища ключей

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

az keyvault create \
  --name $AZURE_KEYVAULT \
  --resource-group $AZURE_RESOURCE_GROUP \
  --location $LOCATION \
  --enable-rbac-authorization true

Снова сохраните id из выходных данных JSON предыдущей команды в качестве переменной среды:

AZURE_KEYVAULT_ID=<id>

Предоставьте себе роль администратора Key Vault в новом хранилище ключей:

az role assignment create \
  --scope $AZURE_KEYVAULT_ID \
  --role "Key Vault Administrator" \
  --assignee-object-id $MY_AZURE_ID \
  --assignee-principal-type User

Назначьте идентификатор центра разработки роли Пользователя секретов Key Vault.

az role assignment create \
  --scope $AZURE_KEYVAULT_ID \
  --role "Key Vault Secrets User" \
  --assignee-object-id $AZURE_DEVCENTER_PRINCIPAL_ID \
  --assignee-principal-type ServicePrincipal

3. Создание и настройка репозитория GitHub

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

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

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

  1. Создайте новый репозиторий GitHub из примера шаблона :

    снимок экрана, на котором показана страница GitHub создания нового репозитория.

  2. Если у вас нет платной учетной записи GitHub, задайте для репозитория значение public.

  3. Выберите Создать репозиторий.

3.2 Защита основной ветви репозитория

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

Примечание.

Защищенные ветви доступны в общедоступных репозиториях с GitHub Free и GitHub Free для организаций, а также в общедоступных и частных репозиториях с GitHub Pro, GitHub Team, GitHub Enterprise Cloud и GitHub Enterprise Server. Дополнительные сведения см. в планах GitHub .

  1. Если он еще не открыт, перейдите на главную страницу репозитория.

  2. Выберите Параметры в меню в верхней части окна:

    снимок экрана со страницей репозитория GitHub. Выделены параметры.

  3. В левой боковой панели в разделе кода и автоматизации выберите Ветви:

    снимок экрана со страницей параметров. Выделены ветви.

  4. В разделе правил защиты ветвивыберите Добавить набор правил ветви.

    снимок экрана: страница правил защиты веток. Выделена функция добавления набора правил ветки.

  5. На странице Набор правил новой ветви в поле Имя набора правил введите CI-CD-tutorial-ruleset:

    снимок экрана с полем

  6. В разделе Целевые ветвивыберите Добавить цель, а затем выберите Включить основные ветви или Включить все ветви:

    снимок экрана с разделом

  7. В разделе Правила ветви выберите Требовать запрос на слияние перед объединением:

    снимок экрана: правила ветви. Перед объединением флажка

  8. По желанию можно включить дополнительных правил защиты.

  9. Выберите Создать.

3.3 Настройка переменных репозитория

  1. В разделе Безопасность боковой панели выберите Секреты и Переменные, а затем выберите Действия:

    снимок экрана: раздел

  2. Выберите вкладку переменных.

  3. Для каждого элемента в следующей таблице:

    1. Выберите Новую переменную репозитория.
    2. В поле имени введите имя переменной.
    3. В поле значение введите значение, описанное в таблице.
    4. Выберите "Добавить переменную".
    Имя переменной Значение переменной
    AZURE_DEVCENTER Имя центра разработки
    AZURE_PROJECT Имя проекта
    AZURE_CATALOG Задайте параметры окружения
    ЭЛЕМЕНТ_КАТАЛОГА_AZURE Установите FunctionApp
    AZURE_SUBSCRIPTION_ID Идентификатор подписки Azure
    AZURE_TENANT_ID (идентификатор арендатора Azure) Идентификатор клиента Azure

    снимок экрана: страница переменных с таблицей переменных.

3.4. Создание личного маркера доступа GitHub

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

Примечание.

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

  1. В правом верхнем углу любой страницы на GitHub.com выберите фотографию профиля, а затем выберите Параметры.

  2. На левой боковой панели выберите параметры разработчика .

  3. На левой боковой панели в разделе Личные токены доступавыберите Тонко настроенные токены, а затем выберите Создать новый токен:

    скриншот с параметрами личного доступа к токенам GitHub. Выделены детализированные токены и параметры создания нового токена.

  4. На странице нового детализированного личного токена доступа, под "Имя токена", введите имя для токена.

  5. В разделе "Срок действия" выберите срок действия маркера.

  6. В разделе владелец ресурсавыберите имя пользователя GitHub.

  7. В разделе Доступ к репозиториювыберите Только выбранные репозитории. В разделе Выбранные репозиториивыполните поиск и выберите созданный репозиторий:

    снимок экрана с параметрами доступа к репозиторию GitHub. Выделен параметр

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

    снимок экрана с разрешениями репозитория GitHub. Выделен раздел

  9. Щелкните Создать маркер.

  10. Скопируйте и сохраните личный маркер доступа. Вы не сможете снова просмотреть его.

3.5 Сохраните ваш личный токен доступа в хранилище ключей

Затем сохраните личный маркер доступа как секрет хранилища ключей с именем pat.

az keyvault secret set \
    --name pat \
    --vault-name $AZURE_KEYVAULT \
    --value <personalAccessToken>

4. Подключение каталога к центру разработки

В средах развертывания Azure каталог — это репозиторий, содержащий набор определений среды. Элементы каталога состоят из шаблона инфраструктуры как кода (IaC) и файла среды, который выступает в качестве манифеста. Шаблон определяет среду, а файл среды предоставляет метаданные о шаблоне. Команды разработчиков используют определения среды из каталога для создания сред.

Шаблон, используемый для создания репозитория GitHub, содержит каталог в папке Среды.

Добавление каталога в центр разработки

В следующей команде замените < Organization/Repository > на имя организации и репозитория GitHub:

az devcenter admin catalog create \
    --name Environments \
    --resource-group $AZURE_RESOURCE_GROUP \
    --dev-center $AZURE_DEVCENTER \
    --git-hub path="/Environments" branch="main" secret-identifier="https://$AZURE_KEYVAULT.vault.azure.net/secrets/pat" uri="https://github.com/< Organization/Repository >.git"

5. Настройка идентификаторов развертывания

OpenID Connect в сочетании с GitHub Actions — это метод проверки подлинности, использующий короткие токены для обеспечения безопасности. Это рекомендуемый способ проверки подлинности GitHub Actions в Azure.

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

5.1 Создание удостоверений развертывания

  1. Зарегистрируйте приложения и основные службы Microsoft Entra для каждого из трех типов среды.

    Создайте приложение Microsoft Entra для Dev:

    az ad app create --display-name "$AZURE_PROJECT-Dev"
    

    Эта команда выводит JSON с id, который используется при создании федеративных учетных данных с помощью API Graph, а также с appId (также называемым идентификатором клиента ).

    Задайте следующие переменные среды:

    DEV_AZURE_CLIENT_ID=<appId>
    DEV_APPLICATION_ID=<id>
    

    Повторите эти действия для теста :

    az ad app create --display-name "$AZURE_PROJECT-Test"
    
    TEST_AZURE_CLIENT_ID=<appId>
    TEST_APPLICATION_ID=<id>
    

    Повторите шаги для Prod:

    az ad app create --display-name "$AZURE_PROJECT-Prod"
    
    PROD_AZURE_CLIENT_ID=<appId>
    PROD_APPLICATION_ID=<id>
    
  2. Создайте основной объект службы для каждого приложения.

    Выполните следующую команду, чтобы создать новую учетную запись службы для Dev:

     az ad sp create --id $DEV_AZURE_CLIENT_ID
    

    Эта команда создает выходные данные JSON с другой id, которая будет использована на следующем этапе.

    Задайте следующую переменную среды:

    DEV_SERVICE_PRINCIPAL_ID=<id>
    

    Повторите эти действия для теста :

     az ad sp create --id $TEST_AZURE_CLIENT_ID
    
    TEST_SERVICE_PRINCIPAL_ID=<id>
    

    Повторите шаги для Prod:

     az ad sp create --id $PROD_AZURE_CLIENT_ID
    
    PROD_SERVICE_PRINCIPAL_ID=<id>
    
  3. Выполните следующие команды, чтобы создать новые учетные данные федеративного удостоверения для каждого приложения Microsoft Entra.

    В каждой из трех следующих команд замените < Organization/Repository > на имя организации и репозитория GitHub.

    Создайте федеративное удостоверение личности для Dev.

    az rest --method POST \
        --uri "https://graph.microsoft.com/beta/applications/$DEV_APPLICATION_ID/federatedIdentityCredentials" \
        --body '{"name":"ADEDev","issuer":"https://token.actions.githubusercontent.com","subject":"repo:< Organization/Repository >:environment:Dev","description":"Dev","audiences":["api://AzureADTokenExchange"]}'
    

    Создайте учетные данные для test:

    az rest --method POST \
        --uri "https://graph.microsoft.com/beta/applications/$TEST_APPLICATION_ID/federatedIdentityCredentials" \
        --body '{"name":"ADETest","issuer":"https://token.actions.githubusercontent.com","subject":"repo:< Organization/Repository >:environment:Test","description":"Test","audiences":["api://AzureADTokenExchange"]}'
    

    Создайте учетные данные для Prod:

    az rest --method POST \
        --uri "https://graph.microsoft.com/beta/applications/$PROD_APPLICATION_ID/federatedIdentityCredentials" \
        --body '{"name":"ADEProd","issuer":"https://token.actions.githubusercontent.com","subject":"repo:< Organization/Repository >:environment:Prod","description":"Prod","audiences":["api://AzureADTokenExchange"]}'
    

5.2 Назначение ролей идентификаторам развертывания

  1. Назначьте для каждого идентификатора развертывания роль Читателя в проекте.

    az role assignment create \
        --scope "$AZURE_PROJECT_ID" \
        --role Reader \
        --assignee-object-id $DEV_SERVICE_PRINCIPAL_ID \
        --assignee-principal-type ServicePrincipal
    
    az role assignment create \
        --scope "$AZURE_PROJECT_ID" \
        --role Reader \
        --assignee-object-id $TEST_SERVICE_PRINCIPAL_ID \
        --assignee-principal-type ServicePrincipal
    
    az role assignment create \
        --scope "$AZURE_PROJECT_ID" \
        --role Reader \
        --assignee-object-id $PROD_SERVICE_PRINCIPAL_ID \
        --assignee-principal-type ServicePrincipal
    
  2. Назначьте роль пользователя для сред развертывания соответствующему типу среды для каждой учетной записи развертывания.

    az role assignment create \
        --scope "$AZURE_PROJECT_ID/environmentTypes/Dev" \
        --role "Deployment Environments User" \
        --assignee-object-id $DEV_SERVICE_PRINCIPAL_ID \
        --assignee-principal-type ServicePrincipal
    
    az role assignment create \
        --scope "$AZURE_PROJECT_ID/environmentTypes/Test" \
        --role "Deployment Environments User" \
        --assignee-object-id $TEST_SERVICE_PRINCIPAL_ID \
        --assignee-principal-type ServicePrincipal
    
    az role assignment create \
        --scope "$AZURE_PROJECT_ID/environmentTypes/Prod" \
        --role "Deployment Environments User" \
        --assignee-object-id $PROD_SERVICE_PRINCIPAL_ID \
        --assignee-principal-type ServicePrincipal
    

6. Настройка сред GitHub

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

Создайте среду Dev, Testи Prod, которые соответствуют типам среды в проекте "Среды развертывания Azure".

Примечание.

Среды, секреты среды и правила защиты среды доступны в общедоступных репозиториях для всех продуктов. Для доступа к средам, секретам среды и ветвям развертывания в частных или внутренних репозиториях необходимо использовать GitHub Pro, GitHub Team или GitHub Enterprise. Для доступа к другим правилам защиты среды в частных или внутренних репозиториях необходимо использовать GitHub Enterprise. Дополнительные сведения см. в планах GitHub .

6.1 Создание среды разработки

  1. В GitHub перейдите на главную страницу репозитория.

  2. Под именем репозитория выберите Параметры. Если вкладка "Параметры " не отображается, выберите раскрывающееся меню ... и выберите параметры.

  3. В левой боковой панели выберите среды.

  4. Выберите Создать среду и введите dev для имени среды, а затем выберите Настроить среду:

    снимок экрана, на котором показана область

  5. В разделе "секреты среды"выберите "Добавить секрет среды", а затем введите AZURE_CLIENT_ID в поле "Имя" .

    снимок экрана: панель

  6. В поле значение введите идентификатор клиента (appId) для созданного ранее приложения Dev Microsoft Entra (сохранено в качестве переменной среды $DEV_AZURE_CLIENT_ID):

    Снимок экрана окна

  7. Выберите Добавить секрет.

6.2. Создание тестовой среды

Вернитесь на основную страницу раздела "Среды", выбрав Среды в левой боковой панели.

  1. Выберите Новая среда, введите Тест для имени среды, а затем выберите Настроить среду.

  2. В разделе "секреты среды"выберите "Добавить секрет среды", а затем введите AZURE_CLIENT_ID в поле "Имя" .

  3. В поле значение введите идентификатор клиента (appId) для созданного ранее приложения Test Microsoft Entra (сохранено в качестве переменной среды $TEST_AZURE_CLIENT_ID).

  4. Выберите Добавить секрет.

6.3 Создание среды Prod

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

  1. Выберите Создать среду, введите Prod для имени среды, а затем выберите Настроить среду.

  2. В разделе "секреты среды"выберите "Добавить секрет среды", а затем введите AZURE_CLIENT_ID в поле "Имя" .

  3. В поле значения введите идентификатор клиента (appId) для созданного ранее приложения Prod Microsoft Entra (сохранено в качестве переменной среды $PROD_AZURE_CLIENT_ID).

  4. Выберите Добавить секрет.

Затем назначьте себя в качестве обязательного рецензента для этой среды. При попытке развернуть Prod, GitHub Actions ожидает одобрения перед началом. Пока задание ожидает утверждения, оно имеет состояние ожидании. Если задание не утверждено в течение 30 дней, оно автоматически неудаётся.

Дополнительные сведения о средах и необходимых утверждениях см. в разделе Использование сред для развертывания.

  1. Выберите Обязательные рецензенты.

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

  3. Выберите Сохранить правила защиты.

Наконец, настройте main в качестве ветви развертывания:

  1. В списке ветвей и тегов развертывания выберите выбранные ветви и теги.

  2. Выберите Добавить правило развертывания ветви или тега, убедитесь, что выбран Тип ссылки: Ветвь, а затем введите main в поле Шаблон имени.

  3. Выберите Добавить правило.

7. Протестируйте конвейер CI/CD

В этом разделе вы вносите некоторые изменения в репозиторий и тестируете конвейер CI/CD.

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

  1. В Git Bash используйте cd для переключения в папку, в которой необходимо клонировать репозиторий локально.

  2. Клонируйте репозиторий. Обязательно замените < Organization/Repository > в следующей команде именем организации и репозитория GitHub.

    git clone https://github.com/< Organization/Repository >.git
    
  3. Перейдите в клонированную папку:

    cd <repository>
    
  4. Создайте новую ветвь и опубликуйте ее удаленно:

    git checkout -b feature1
    
    git push -u origin feature1
    

    Новая среда, связанная с этой ветвью, создается в Azure.

  5. На сайте GitHub перейдите на главную страницу созданного репозитория.

  6. В поле имени репозитория выберите Действия:

    Вы, вероятно, увидите, как запускается новый рабочий процесс создания среды.

7.2. Изменение кода

  1. Откройте локально клонированного репозитория в Visual Studio Code.

  2. В папке ADE.Туториал внесите изменения в файл.

  3. Сохраните изменения.

Примените изменения для обновления среды

  1. Подготовьте ваши изменения и отправьте в ветку feature1.

    git add .
    git commit -m '<commit message>'
    git push
    
  2. На странице Действия вашего репозитория вы увидите рабочий процесс обновления среды.

7.4. Создание pull request’а

  1. Создайте пулл-реквест на GitHub main <- feature1.

  2. На странице действий репозитория вы увидите, что новый рабочий процесс запускается для создания среды, относящейся к pull request. Используется тип тестовой среды.

7.5 Слияние запроса на вытягивание

  1. На GitHub перейдите к созданному вами pull-реквесту.

  2. Объединить pull request.

    Ваши изменения опубликованы в производственной среде, а среды для веток и pull request удалены.

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

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

Чтобы удалить ресурсы с помощью портал Azure, выполните следующие действия.

  1. Нажмите кнопку меню в левом верхнем углу и выберите группы ресурсов.

  2. Выберите созданную группу ресурсов из списка.

  3. Выберите команду Удалить группу ресурсов.

  4. Введите имя группы ресурсов. Затем выберите Удалить.

Чтобы удалить ресурсы с помощью Azure CLI, введите следующую команду:

az group delete --name <my-dev-center-rg>

Помните, что удаление группы ресурсов удаляет все ресурсы в ней.