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

  • 12 мин

В этом уроке вы опробуете на практике процесс отправки запроса на вытягивание и слияния изменений с ветвью main, чтобы все могли воспользоваться вашей работой.

При Создании конвейера сборки с помощью Azure Pipelines вы создали ветвь Git с именем build-pipeline, в которой вы определили базовый конвейер сборки для веб-сайта Space Game. Вспомните, что определение сборки находится в файле с именем azure-pipelines.yml.

Хотя ваша ветвь создает артефакт сборки, эта работа существует только в build-pipeline ветви. Необходимо объединить вашу ветвь с ветвью main.

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

Прежде чем начать, давайте проверка в с Марой и Энди.

Энди: Привет, Мара. Я знаю, что у вас есть конвейер сборки, работающий в Azure. Я добавляю функцию на веб-сайт, и я хочу увидеть процесс сборки для себя. Готовы ли мы сделать это?

Мара: Абсолютно. Я создал конвейер в ветви. Давай создадим запрос на вытягивание и объединим его с main, чтобы ты тоже мог использовать конвейер?

Энди: Звучит здорово. Давай посмотрим.

Создание ветви и добавление начального кода

Хотя вы можете использовать конвейер сборки, созданный в предыдущем модуле, давайте создадим новую ветвь с именем code-workflow. Эта ветвь основана на main, так что можно опробовать процесс с самого начала.

  1. В Visual Studio Code откройте интегрированный терминал.

  2. Перейдите main в ветвь:

    git checkout main

  3. Убедитесь, что у вас есть последняя версия кода из GitHub:

    git pull origin main

  4. Создайте ветвь с именем code-workflow:

    git checkout -B code-workflow

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

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

    Теперь это безопасно, чтобы внести все необходимые изменения, так как вы находитесь в собственной локальной ветви. Если вы хотите увидеть, какая ветвь включена, выполните команду git branch -v.

  5. В проводнике откройте azure-pipelines.yml и замените его содержимое следующим образом:

    trigger:
- '*'

pool:
  vmImage: 'ubuntu-20.04'
  demands:
  - npm

variables:
  buildConfiguration: 'Release'
  wwwrootDir: 'Tailspin.SpaceGame.Web/wwwroot'
  dotnetSdkVersion: '6.x'

steps:
- task: UseDotNet@2
  displayName: 'Use .NET SDK $(dotnetSdkVersion)'
  inputs:
    version: '$(dotnetSdkVersion)'

- task: Npm@1
  displayName: 'Run npm install'
  inputs:
    verbose: false

- script: './node_modules/.bin/node-sass $(wwwrootDir) --output $(wwwrootDir)'
  displayName: 'Compile Sass assets'

- task: gulp@1
  displayName: 'Run gulp tasks'

- script: 'echo "$(Build.DefinitionName), $(Build.BuildId), $(Build.BuildNumber)" > buildinfo.txt'
  displayName: 'Write build info'
  workingDirectory: $(wwwrootDir)

- task: DotNetCoreCLI@2
  displayName: 'Restore project dependencies'
  inputs:
    command: 'restore'
    projects: '**/*.csproj'

- task: DotNetCoreCLI@2
  displayName: 'Build the project - $(buildConfiguration)'
  inputs:
    command: 'build'
    arguments: '--no-restore --configuration $(buildConfiguration)'
    projects: '**/*.csproj'

- task: DotNetCoreCLI@2
  displayName: 'Publish the project - $(buildConfiguration)'
  inputs:
    command: 'publish'
    projects: '**/*.csproj'
    publishWebProjects: false
    arguments: '--no-build --configuration $(buildConfiguration) --output $(Build.ArtifactStagingDirectory)/$(buildConfiguration)'
    zipAfterPublish: true

- task: PublishBuildArtifacts@1
  displayName: 'Publish Artifact: drop'
  condition: succeeded()

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

Отправка ветви в GitHub

Здесь вы будете отправлять ветвь code-workflow в GitHub и смотреть, как Azure Pipelines создает приложение.

  1. В терминале выполните команду git status , чтобы узнать, что в вашей ветви существует незафиксированная работа:

    git status

    Вы увидите, что файл azure-pipelines.yml был изменен. Вскоре вы зафиксируете это в своей ветви, но сначала нужно убедиться, что Git отслеживает этот файл. Это называется помещением на промежуточное хранение и обработку.

    При запуске git commitфиксируются только промежуточные изменения. Затем выполните команду git add, чтобы добавить azure-pipelines.yml в область промежуточного хранения или индекс.

  2. Выполните следующую команду git add, чтобы добавить azure-pipelines.yml в область промежуточного хранения.

    git add azure-pipelines.yml

  3. Выполните следующую команду git commit, чтобы зафиксировать промежуточный файл в ветви code-workflow:

    git commit -m "Add the build configuration"

    Аргумент -m задает сообщение фиксации. Сообщение фиксации становится частью журнала измененного файла. Оно помогает рецензентам понять смысл изменения, а тем, кто будет поддерживать код позже, — проследить изменения файла с течением времени.

    Совет

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

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

  4. Выполните следующую команду git push, чтобы отправить (загрузить) ветвь code-workflow в свой репозиторий на GitHub:

    git push origin code-workflow

  5. В качестве дополнительного шага перейдите к проекту в Azure Pipelines и трассируйте сборку по мере его выполнения.

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

    trigger:
- '*'

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

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

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

Здесь вы создадите запрос на вытягивание для своей ветви:

  1. В браузере войдите в GitHub.

  2. Перейдите в репозиторий mslearn-tailspin-spacegame-web .

  3. В раскрывающемся списке Branch (Ветвь) выберите свою ветвь code-workflow.

    Screenshot of GitHub showing how to select the branch from the drop-down menu.

  4. Чтобы запустить запрос на вытягивание, выберите пункт Участие и щелкните Открыть запрос на вытягивание.

    Screenshot of GitHub showing the location of the Open pull request button.

  5. Убедитесь, что база указывает вилку репозитория, а не репозиторий Майкрософт.

    Выбор выглядит следующим образом:

    Screenshot of GitHub confirming that the branch can be merged.

    Важно!

    Этот шаг важен, так как вы не можете объединить изменения в репозиторий Майкрософт. Убедитесь, что базовый репозиторий указывает на вашу учетную запись GitHub, а не на MicrosoftDocs.

    Если вы в конечном итоге запрос на вытягивание в MicrosoftDocs, просто закройте запрос на вытягивание и повторите эти действия.

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

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

    • Название:

      Настройка Azure Pipelines

    • Описание.

      Эта конфигурация конвейера создает приложение и создает сборку для конфигурации выпуска.

  7. Чтобы завершить запрос на вытягивание, нажмите кнопку "Создать запрос на вытягивание".

    Этот шаг не объединяет код. Он сообщает другим пользователям, что вы предложили изменения для слияния с ветвью main.

    Screenshot of GitHub showing the pull request description and the location of the Create pull request button.

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

    Screenshot of GitHub showing build checks running in Azure Pipelines.

    Как и при отправить ветвь в GitHub, запрос на вытягивание по умолчанию активирует Microsoft Azure Pipelines для создания приложения.

    Совет

    Если состояние сборки не отображается сразу, подождите несколько минут или обновите страницу.

  8. При необходимости выберите ссылку "Сведения" , а затем трассировку сборки по мере перемещения по конвейеру.

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

  9. Вернитесь к запросу на вытягивание на GitHub.

    Дождитесь завершения сборки. Теперь вы готовы объединить запрос на вытягивание.

    Screenshot of GitHub showing successful build checks in Azure Pipelines.

  10. Выберите запрос на вытягивание слиянием и нажмите кнопку "Подтвердить слияние".

  11. Чтобы удалить ветвь code-workflow из GitHub, выберите Delete branch (Удалить ветвь).

    Screenshot of GitHub showing the location of the Delete branch button.

    После объединения запроса на вытягивание можно полностью удалить ветвь из GitHub. На самом деле, это распространенная практика, потому что ветвь больше не нужна. Изменения объединяются, и вы по-прежнему можете найти сведения об изменениях на GitHub или из командной строки. Удаление объединенной ветви также помогает другим пользователям видеть только те действия, которые сейчас активны.

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

    При удалении ветви на GitHub эта ветвь не удаляется из локальной системы. Для этого передайте переключатель -d в git branch команду.

Сколько раз создается изменение?

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

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

trigger:
  branches:
    include:
    - '*'     # build all branches
  paths:
    exclude:
    - docs/*  # exclude the docs folder

По умолчанию сборка активируется при отправке изменения в любой файл в любой ветви.

Сборка непрерывной интеграции (CI) — это сборка, которая выполняется при отправке изменения в ветвь.

Сборка запроса на вытягивание (PR) — это сборка, которая выполняется при открытии запроса на вытягивание или при отправке дополнительных изменений в существующий запрос на вытягивание.

Изменения, внесенные через ветвь code-workflow , создаются в трех условиях:

  • Сборка CI происходит при отправке изменений в code-workflow ветвь.
  • Сборка pr происходит при открытии запроса на вытягивание в code-workflow ветви в main ветви.
  • Окончательная сборка CI происходит после слияния запроса на вытягивание с ветвью main.

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

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

В качестве дополнительного шага перейдите в Azure Pipelines и просмотрите окончательную сборку CI в main ветви.