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


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

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

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

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

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

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

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

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

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

Необходимые компоненты

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

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

  • Тип среды Prod содержит одну рабочую среду.
  • Новая среда создается в Dev для каждой ветвь компонента.
  • Новая среда создается в тестовом режиме для каждого запроса на вытягивание.

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>

Предоставьте себе роль Администратор istrator 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 из примера шаблона.

    Screenshot showing the GitHub create repository from template page.

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

  3. Щелкните Create repository from template (Создание репозитория из шаблона).

  4. На вкладке "Действия" обратите внимание, что действие "Создать среду" завершается сбоем. Это поведение ожидается, вы можете перейти к следующему шагу.

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

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

Примечание.

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

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

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

    Screenshot showing the GitHub repository page with settings highlighted.

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

    Screenshot showing the settings page, with branches highlighted.

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

    Screenshot showing the branch protection rule page, with Add branch protection rule highlighted.

  5. В разделе " Шаблон имени ветви" введите main.

    Screenshot showing the branch name pattern text box, with main highlighted.

  6. В разделе "Защита соответствующих ветвей" выберите " Требовать запрос на вытягивание" перед слиянием.

    Screenshot showing protect matching branches with Require a pull request before merging selected and highlighted.

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

  8. Нажмите кнопку создания.

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

Примечание.

Переменные конфигурации для GitHub Actions находятся в бета-версии и подлежат изменению.

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

    Screenshot showing the Security section of the sidebar with Actions highlighted.

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

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

    1. Выберите новую переменную репозитория.
    2. В поле "Имя" введите имя переменной.
    3. В поле "Значение" введите значение, описанное в таблице.
    4. Выберите "Добавить переменную".
    Имя переменной Значение переменной
    AZURE_DEVCENTER Имя центра разработки
    AZURE_PROJECT Имя проекта
    AZURE_CATALOG Задайте для параметра "Среды"
    AZURE_CATALOG_ITEM Задайте для параметра FunctionApp значение "FunctionApp"
    AZURE_SUBSCRIPTION_ID идентификатор подписки Azure;
    AZURE_TENANT_ID Идентификатор клиента Azure

    Screenshot showing the variables page with the variables table.

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

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

Примечание.

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

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

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

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

    Screenshot showing the GitHub personal access token options, with Fine-grained tokens and Generate new token highlighted.

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

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

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

  7. В разделе "Доступ к репозиторию" выберите только репозитории , а затем в раскрывающемся списке "Выбранные репозитории ", выполните поиск и выберите созданный репозиторий.

    Screenshot showing GitHub repository access options, with Only select repositories highlighted.

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

    Screenshot showing GitHub repository permissions with Contents highlighted.

  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 Подключение с GitHub Actions — это метод проверки подлинности, который использует короткие маркеры для обеспечения защищенной безопасности. Это рекомендуемый способ проверки подлинности GitHub Actions в Azure.

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

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

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

    Создайте приложение Microsoft Entra для разработки.

    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. Создайте субъект-службу для каждого приложения.

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

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

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

    Создайте учетные данные федеративного удостоверения для разработки.

    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"]}'
    

    Для тестирования.

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

Создайте среды разработки, тестирования и prod , которые сопоставляются с типами среды в проекте "Среды развертывания Azure".

Примечание.

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

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

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

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

  3. На левой боковой панели выберите "Среды".

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

    Screenshot showing the Environments Add pane, with the environment name Dev, and Configure Environment highlighted.

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

    Screenshot showing the Environment Configure Dev pane, with Add secret highlighted.

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

    Screenshot of the Add secret box with the name AZURE CLIENT ID, the value set to an ID number, and add secret highlighted.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  1. В раскрывающемся списке "Ветви развертывания" выберите выбранные ветви.

  2. Выберите " Добавить правило ветви развертывания" и введите main шаблон имени ветви.

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

7. Тестирование конвейера CI/CD

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

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

  1. В терминале 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. Откройте локально клонированного репозитория в VS Code.

  2. В ADE. Папка учебника, внесите изменения в файл.

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

7.3. Отправка изменений для обновления среды

  1. Этап изменений и отправка в feature1 ветвь.

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

7.4. Создание запроса на вытягивание

  1. Создайте запрос main <- feature1на вытягивание GitHub.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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