演習 - 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 の様子を見てみましょう。

アンディ： こんにちは、Mara。 あなたが Azure で実行されるビルド パイプラインを準備したことは知っています。 私はウェブサイトに機能を追加しています、そして私は自分のビルドプロセスを見たいと思います。 それを行う準備はできていますか。

マラ： そうですよ。 ブランチにパイプラインを作成しました。 あなたもそのパイプラインを使用できるように、pull request を作成して、それを 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 にあなたのブランチをプッシュする

ここでは、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. [ ブランチ ] ドロップダウン リストで、 code-workflow ブランチを選択します。

    ドロップダウン メニューからブランチを選択する方法を示す GitHub のスクリーンショット。

  4. pull request を開始するには、[ 投稿 ] を選択し、[ pull request を開く] を選択します。

    [プル要求を開く] ボタンの場所を示す GitHub のスクリーンショット。

  5. ベースが、Microsoft リポジトリではなくフォークされたリポジトリを指定していることを確認します。

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

    ブランチをマージできることを確認する GitHub のスクリーンショット。

    重要

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

    MicrosoftDocs に対するプル要求が発生した場合は、pull request を閉じて、これらの手順を繰り返します。

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

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

    • タイトル:

      Azure Pipelines の構成

    • 説明:

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

  7. pull request を完了するには、[ pull request の作成] を選択します。

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

    プル要求の説明と [pull request の作成] ボタンの場所を示す GitHub のスクリーンショット。

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

    Azure Pipelines で実行されているビルド チェックを示す GitHub のスクリーンショット。

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

    ヒント

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

  8. 必要に応じて、[ 詳細 ] リンクを選択し、パイプライン内を移動するビルドをトレースします。

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

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

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

    Azure Pipelines でのビルド チェックの成功を示す GitHub のスクリーンショット。

  10. [ プル要求のマージ] を選択し、[ マージの確認] を選択します。

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

    [ブランチの削除] ボタンの場所を示す GitHub のスクリーンショット。

    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) ビルドは、ブランチに変更をプッシュするときに実行されるビルドです。

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

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

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

PR ビルドは、提案された変更がmainまたは別のターゲット ブランチにマージされた後に正しく機能することを確認するのに役立ちます。

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

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