演習 - pull request を作成する

  • 12 分

このユニットでは、pull request を送信し、あなたの変更を main ブランチにマージして、全員が作業の恩恵を受けることができるようにするプロセスを練習します。

「Azure Pipelines を使用してビルド パイプラインを作成する」では、build-pipeline という名前の Git ブランチを作成しました。そこで、Space Game Web サイトの基本的なビルド パイプラインを定義しました。 ビルド定義は、azure-pipelines.yml という名前のファイルにあることを思い出してください。

あなたのブランチではビルド成果物が生成されますが、その作業は build-pipeline ブランチにのみ存在します。 あなたのブランチを main ブランチにマージする必要があります。

pull request は、他の開発者に、必要に応じてレビューする準備ができたコードがあること、あなたの変更内容を main ブランチなどの別のブランチにマージしたいことを通知するものであることを思い出してください。

開始する前に、Mara と Andy の様子を見てみましょう。

Andy: やあ、Mara。 あなたが Azure で実行されるビルド パイプラインを準備したことは知っています。 私は Web サイトに機能を追加しようとしていて、ビルド プロセスを自分自身で確認したいと考えてます。 それを行う準備はできていますか。

Mara: もちろんです。 ブランチにパイプラインを作成しました。 あなたもそのパイプラインを使用できるように、pull request を作成して、それを main にマージしてみませんか。

Andy: それはすばらしいですね。 例を見てみましょう。

ブランチを作成してスタート コードを追加する

前のモジュールで構築したビルド パイプラインを使用することもできますが、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 にあなたのブランチをプッシュする

ここでは、GitHub に code-workflow ブランチをプッシュして、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 コマンドを実行して、GitHub 上にある自分のリポジトリに code-workflow ブランチをプッシュ (アップロード) します。

    git push origin code-workflow

  5. 省略可能なステップとして、Azure Pipelines であなたのプロジェクトに移動し、その実行中にビルドをトレースします。

    このビルドは "CI ビルド" と呼ばれます。 パイプライン構成では、"トリガー" と呼ばれるものを使用して、どのブランチがビルド プロセスに参加するかを制御しています。 ここでは、"*" で、すべてのブランチを指定しています。

    trigger:
- '*'

    後で、必要なブランチだけから構築を行うようにパイプライン構成を制御する方法について説明します。

    ビルドが正常に完了し、ビルドされた Web アプリケーションを含む成果物が生成されていることがわかります。

pull request を作成する

ここでは、あなたのブランチの pull request を作成します。

  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. pull request を開始するには、[Contribute]、[Open pull request] の順に選択します。

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

  5. [base] で、Microsoft のリポジトリではなく、フォークしたあなたのリポジトリを指定していることを確認します。

    選択内容は次のようになります。

    Screenshot of GitHub confirming that the branch can be merged.

    重要

    Microsoft リポジトリにあなたの変更をマージすることはできないため、この手順は重要です。 基本リポジトリが、MicrosoftDocs ではなくあなたの GitHub アカウントを指し示していることを確認します。

    MicrosoftDocs に対する pull request になってしまった場合は、単に pull request を閉じて、これらの手順を繰り返してください。

    フォークしたリポジトリから作業しているため、このプロセスには余分な手順が伴います。 フォークではなく独自リポジトリを直接操作するときは、main ブランチが既定で選択されます。

  6. pull request のタイトルと説明を入力します。

    • タイトル:

      Azure Pipelines を構成する

    • 説明:

      このパイプライン構成では、アプリケーションをビルドし、リリース構成のためのビルドを生成します。

  7. pull request を完了するため、[プル要求の作成] を選択します。

    この手順では、どのコードもマージしません。 これにより、main ブランチにマージする変更があなたによって提案されたことが他のユーザーに伝えられます。

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

    pull request のウィンドウが表示されます。 Azure Pipelines でのビルドの状態が、pull request の一部として表示されるように構成されていることがわかります。 そうすることで、あなたや他の人が、ビルドを実行しているときにその状態を表示できます。

    Screenshot of GitHub showing build checks running in Azure Pipelines.

    GitHub にブランチをプッシュするときと同様に、pull request は既定で、Microsoft Azure Pipelines によるアプリケーションのビルドをトリガーします。

    ヒント

    ビルドの状態がすぐに表示されるように見えない場合は、少し待つか、ページを更新してください。

  8. (省略可能) [Details] リンクを選択してから、ビルドがパイプライン内を移動するときにビルドをトレースします。

    QA など、プロセスの次のステップにビルドを渡すことができます。 後で、あなたの変更を最後の QA ラボまたは運用環境までプッシュするようにパイプラインを構成できます。

  9. GitHub で、あなたの pull request に戻ります。

    ビルドが完了するまで待ちます。 これで、pull request をマージする準備ができました。

    Screenshot of GitHub showing successful build checks in Azure Pipelines.

  10. [Merge pull request] を選択してから、[Confirm merge] を選択します。

  11. GitHub から code-workflow ブランチを削除するため、[ブランチの削除] を選択します。

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

    pull request をマージした後は、GitHub からブランチを削除してもまったく安全です。 そのブランチはもう不要になっているため、実際にはこれが一般的なやり方です。 変更はマージされますが、変更の詳細は、GitHub で、またはコマンドラインから見つけることができます。 マージされたブランチを削除すると、他の人が現在アクティブな作業のみを表示する助けにもなります。

    Git ブランチは短期の使用が想定されています。 ブランチをマージした後は、そこに追加のコミットをプッシュしたり、2 回目のブランチのマージを行ったりすることはありません。 ほとんどの場合、新機能やバグ修正プログラムに取り掛かるたびに、main ブランチに基づくクリーンなブランチで作業を開始します。

    GitHub でブランチを削除しても、そのブランチはローカル システムから削除されません。 それを行うには、-d スイッチを git branch コマンドに渡します。

変更は何回ビルドされるか

この答えは、ビルド構成がどのように定義されているかに左右されます。 Azure Pipelines を使用すると、ビルドを発生させるイベントを指定する "トリガー" を定義できます。 どのブランチをビルドするかを制御でき、どのファイルによってビルドをトリガーするかさえ制御できます。

たとえば、任意の Git ブランチで変更が GitHub にプッシュされたときにビルドが行われるようにするとします。 しかし、プロジェクトの docs フォルダー内のファイルだけが変更対象の場合は、ビルドを行わないようにします。 ビルド構成には、次の trigger セクションを含めることができます。

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

既定では、任意のブランチ上で、いずれかのファイルに対して変更がプッシュされると、ビルドがトリガーされます。

"継続的インテグレーション" (CI) ビルドは、変更をブランチにプッシュしたときに実行されるビルドです。

"pull request" (PR) ビルドは、pull request を開いたとき、または既存の pull request に対して追加の変更をプッシュしたときに実行されるビルドです。

code-workflow ブランチを通して加えた変更は、3 つの条件のもとでビルドされます。

  • CI ビルドは、変更を code-workflow ブランチにプッシュしたときに行われます。
  • PR ビルドは、code-workflow ブランチで、main ブランチに対する pull request を開いたときに行われます。
  • 最終的な CI ビルドは、pull request が main ブランチにマージされた後に行われます。

PR ビルドは、提出した変更が、main または別のターゲット ブランチにマージされた後に正常に機能するだろうことを確認する助けとなります。

最終的な CI ビルドでは、PR がマージされた後も変更が正常であることが確認されます。

省略可能な手順として、Azure Pipelines にアクセスし、main ブランチで最終的な CI ビルドが行われることを確認します。