パイプラインをカスタマイズする
Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019
これは、パイプラインをカスタマイズする一般的な方法に関するステップバイステップ ガイドです。
前提条件
「最初の パイプラインを作成する 」の手順に従って、動作するパイプラインを作成します。
ファイルを理解するazure-pipelines.yml
パイプラインは、リポジトリ内の YAML ファイルを使用して定義されます。 通常、このファイルには という名前が付けられ azure-pipelines.yml 、リポジトリのルートにあります。
Azure Pipelines の [パイプライン] ページに移動し、作成したパイプラインを選択し、パイプラインのコンテキスト メニューで [編集] を選択して、パイプラインの YAML エディターを開きます。
Note
Azure DevOps ポータルでパイプラインを表示および管理する方法については、「 パイプラインの移動」を参照してください。
YAML ファイルの内容を調べます。
trigger:
- main
pool:
vmImage: 'ubuntu-latest'
steps:
- task: Maven@4
inputs:
mavenPomFile: 'pom.xml'
mavenOptions: '-Xmx3072m'
javaHomeOption: 'JDKVersion'
jdkVersionOption: '1.11'
jdkArchitectureOption: 'x64'
publishJUnitResults: false
testResultsFiles: '**/surefire-reports/TEST-*.xml'
goals: 'package'
Note
YAML ファイルの内容は、開始したサンプル リポジトリ、または Azure Pipelines で行われたアップグレードによって異なる場合があります。
このパイプラインは、チームがリポジトリのメイン ブランチに変更をプッシュするか、プル要求を作成するたびに実行されます。 Microsoft でホストされている Linux マシン上で実行されます。 パイプライン プロセスには、Maven タスクを実行する 1 つのステップがあります。
ビルドするプラットフォームを変更する
さまざまな開発言語用の SDK とツールが既に含まれている Microsoft ホスト型エージェント でプロジェクトをビルドできます。 または、必要な特定のツールで セルフホステッド エージェント を使用することもできます。
ビルドで [ パイプラインの編集] アクションを選択するか、パイプラインのメイン ページから [編集 ] を選択して、パイプラインのエディターに移動します。
現在、パイプラインは Linux エージェントで実行されます。
pool: vmImage: "ubuntu-latest"Windows や Mac などの別のプラットフォームを選択するには、値を変更します
vmImage。pool: vmImage: "windows-latest"pool: vmImage: "macos-latest"[ 保存] を 選択し、変更を確認して、パイプラインが別のプラットフォームで実行されているのを確認します。
ステップを追加する
パイプラインにステップとして さらにスクリプト または タスク を追加できます。 タスクは、事前にパッケージ化されたスクリプトです。 タスクは、アプリのビルド、テスト、発行、またはデプロイに使用できます。 Java の場合、使用した Maven タスクはテストと発行の結果を処理しますが、タスクを使用してコード カバレッジの結果を発行することもできます。
パイプラインの YAML エディターを開きます。
YAML ファイルの末尾に次のスニペットを追加します。
- task: PublishCodeCoverageResults@1 inputs: codeCoverageTool: "JaCoCo" summaryFileLocation: "$(System.DefaultWorkingDirectory)/**/site/jacoco/jacoco.xml" reportDirectory: "$(System.DefaultWorkingDirectory)/**/site/jacoco" failIfCoverageEmpty: true[ 保存] を選択 し、変更を確認します。
テストとコード カバレッジの結果を表示するには、ビルドを選択し、[ テスト ] タブと [ カバレッジ ] タブに移動します。
複数のプラットフォームにまたがるビルド
複数のプラットフォームでプロジェクトをビルドしてテストできます。 これを行う 1 つの方法は、 と matrixですstrategy。 変数を使用して、パイプラインのさまざまな部分にデータを簡単に配置できます。 この例では、変数を使用して、使用するイメージの名前を渡します。
ファイルで
azure-pipelines.yml、次の内容を置き換えます。pool: vmImage: "ubuntu-latest"次の内容を含みます。
strategy: matrix: linux: imageName: "ubuntu-latest" mac: imageName: "macOS-latest" windows: imageName: "windows-latest" maxParallel: 3 pool: vmImage: $(imageName)[ 保存] を 選択し、変更を確認して、ビルドが 3 つの異なるプラットフォームで最大 3 つのジョブを実行することを確認します。
各エージェントは、一度に 1 つのジョブのみを実行できます。 複数のジョブを並列で実行するには、複数のエージェントを構成する必要があります。 十分な 並列ジョブも必要です。
複数のバージョンを使用してビルドする
その言語の異なるバージョンを使用してプロジェクトをビルドするには、 のバージョンと変数を使用 matrix できます。 この手順では、1 つのプラットフォームで 2 つの異なるバージョンの Java を使用して Java プロジェクトをビルドするか、異なるプラットフォームで異なるバージョンの Java を実行できます。
Note
コンテキストで複数回使用 strategy することはできません。
1 つのプラットフォームと複数のバージョンでビルドする場合は、Maven タスクの前と の後に
azure-pipelines.yml、次のマトリックスをファイルにvmImage追加します。strategy: matrix: jdk10: jdkVersion: "1.10" jdk11: jdkVersion: "1.11" maxParallel: 2次に、maven タスクで次の行を置き換えます。
jdkVersionOption: "1.11"置き換えた後の行は次のとおりです。
jdkVersionOption: $(jdkVersion)変数は必ず、選択した
$(imageName)プラットフォームに戻してください。複数のプラットフォームとバージョンでビルドする場合は、発行タスクの前にファイル内の
azure-pipelines.ymlコンテンツ全体を次のスニペットに置き換えます。trigger: - main strategy: matrix: jdk10_linux: imageName: "ubuntu-latest" jdkVersion: "1.10" jdk11_windows: imageName: "windows-latest" jdkVersion: "1.11" maxParallel: 2 pool: vmImage: $(imageName) steps: - task: Maven@4 inputs: mavenPomFile: "pom.xml" mavenOptions: "-Xmx3072m" javaHomeOption: "JDKVersion" jdkVersionOption: $(jdkVersion) jdkArchitectureOption: "x64" publishJUnitResults: true testResultsFiles: "**/TEST-*.xml" goals: "package"[ 保存] を 選択し、変更を確認して、ビルドで 2 つの異なるプラットフォームと SDK で 2 つのジョブが実行されたことを確認します。
CI トリガーをカスタマイズする
パイプライン トリガーにより、パイプラインが実行されます。 を使用 trigger: すると、更新プログラムをブランチにプッシュするたびにパイプラインを実行できます。 YAML パイプラインは、既定のブランチ (通常 mainは ) で CI トリガーを使用して既定で構成されます。 特定のブランチまたは pull request 検証用にトリガーを設定できます。 pull request 検証トリガーの場合は、次の trigger: 2 つの例に示すように、ステップ pr: を に置き換えます。 既定では、プル要求の変更ごとにパイプラインが実行されます。
トリガーを設定する場合は、ファイルの先頭に次のいずれかのスニペットを追加します
azure-pipelines.yml。trigger: - main - releases/*pr: - main - releases/*ブランチの完全な名前 (例:
main) またはプレフィックスに一致するワイルドカード (例:releases/*) を指定できます。
パイプラインの設定
パイプライン設定は、パイプラインの詳細ページの [その他のアクション
] メニューから表示および構成できます。
- セキュリティ - の管理セキュリティの管理
- 名前の変更/移動 - パイプライン名とフォルダーの場所を編集します。
- 状態バッジ - リポジトリにステータス バッジを追加する
- 削除 - すべてのビルドと関連する成果物を含むパイプラインを削除します。
- スケジュールされた実行 - スケジュールされた実行ビュー
[ 設定] を 選択して、次のパイプライン設定を構成します。
[ パイプラインの設定 ] ウィンドウから、次の設定を構成できます。
新しい実行要求の処理 - パイプラインで新しい実行が開始されないようにしたい場合があります。
- 既定では、新しい実行要求の処理は 有効です。 この設定により、手動実行を含むすべてのトリガーの種類の標準処理が可能になります。
- 一時停止された パイプラインでは、実行要求を処理できますが、これらの要求は実際に開始せずにキューに入れられます。 新しい要求処理が有効になると、キュー内の最初の要求から実行処理が再開されます。
- 無効な パイプラインでは、ユーザーが新しい実行を開始できなくなります。 この設定が適用されている間は、すべてのトリガーも無効になります。
YAML ファイル パス - パイプラインに別の YAML ファイルを使用するように指示する必要がある場合は、そのファイルへのパスを指定できます。 この設定は、YAML ファイルを移動または名前変更する必要がある場合にも役立ちます。
この実行に含まれる作業項目を自動的にリンク する - 特定のパイプライン実行に関連付けられている変更には、作業項目が関連付けられている可能性があります。 これらの作業項目を実行にリンクするには、このオプションを選択します。 [この実行に含まれる作業項目を自動的にリンクする] が選択されている場合は、特定のブランチまたは
*すべてのブランチ (既定値) を指定する必要があります。 ブランチを指定した場合、作業項目はそのブランチの実行にのみ関連付けられます。 を指定*すると、すべての実行に作業項目が関連付けられます。
- 実行が失敗したときに通知を受け取るには、チームの通知を管理する方法に関するページを参照してください。
セキュリティの管理
パイプラインのセキュリティは、[パイプライン] ランディング ページの [その他のアクション ] ページとパイプラインの詳細ページのパイプライン レベルからプロジェクト レベルで構成できます。
パイプライン操作のセキュリティをサポートするには、組み込みのセキュリティ グループにユーザーを追加するか、ユーザーまたはグループの個々のアクセス許可を設定するか、定義済みのロールにユーザーを追加します。 Azure Pipelines のセキュリティは、ユーザーまたは管理者コンテキストから Web ポータルで管理できます。 パイプラインのセキュリティの構成の詳細については、「パイプラインの アクセス許可とセキュリティ ロール」を参照してください。
失敗時に作業項目を作成する
YAML パイプラインには、クラシック ビルド パイプラインのような [失敗時に作業項目を作成する ] 設定はありません。 クラシック ビルド パイプラインは単一ステージであり、 失敗時の作業項目の作成 はパイプライン全体に適用されます。 YAML パイプラインは複数ステージにすることができ、パイプライン レベルの設定が適切でない場合があります。 YAML パイプラインで 失敗した場合に作業項目を作成 するを実装するには、 作業項目の作成 REST API 呼び出しや Azure DevOps CLI az boards work-item create コマンドなどのメソッドをパイプライン内の目的のポイントで使用できます。
次の例には、2 つのジョブがあります。 最初のジョブはパイプラインの作業を表しますが、失敗した場合は 2 番目のジョブが実行され、パイプラインと同じプロジェクトにバグが作成されます。
# When manually running the pipeline, you can select whether it
# succeeds or fails.
parameters:
- name: succeed
displayName: Succeed or fail
type: boolean
default: false
trigger:
- main
pool:
vmImage: ubuntu-latest
jobs:
- job: Work
steps:
- script: echo Hello, world!
displayName: 'Run a one-line script'
# This malformed command causes the job to fail
# Only run this command if the succeed variable is set to false
- script: git clone malformed input
condition: eq(${{ parameters.succeed }}, false)
# This job creates a work item, and only runs if the previous job failed
- job: ErrorHandler
dependsOn: Work
condition: failed()
steps:
- bash: |
az boards work-item create \
--title "Build $(build.buildNumber) failed" \
--type bug \
--org $(System.TeamFoundationCollectionUri) \
--project $(System.TeamProject)
env:
AZURE_DEVOPS_EXT_PAT: $(System.AccessToken)
displayName: 'Create work item on failure'
Note
Azure Boardsでは、アジャイルや Basic など、いくつかの異なるプロセスを使用して作業項目の追跡を構成できます。 各プロセスには異なる作業項目の種類があり、各プロセスですべての作業項目の種類を使用できるわけではありません。 各プロセスでサポートされる作業項目の種類の一覧については、「 作業項目の種類 (WIT)」を参照してください。
前の例では 、ランタイム パラメーター を使用して、パイプラインが成功するか失敗するかを構成します。 パイプラインを手動で実行する場合は、 パラメーターの値を succeed 設定できます。 パイプラインの最初のジョブの 2 番目 script のステップでは、 パラメーターが succeed 評価され、 が false に設定されている場合 succeed にのみ実行されます。
パイプライン内の 2 番目のジョブは、最初のジョブに依存しており、最初のジョブが失敗した場合にのみ実行されます。 2 番目のジョブでは、Azure DevOps CLI az boards work-item create コマンドを使用してバグを作成します。 パイプラインから Azure DevOps CLI コマンドを実行する方法の詳細については、「 YAML パイプラインでコマンドを実行する」を参照してください。
この例では 2 つのジョブを使用しますが、同じ方法を 複数のステージで使用できます。
Note
また、YAML マルチステージ パイプラインをサポートする リリース時のバグの作成エラー などのマーケットプレース拡張機能を使用することもできます。
次のステップ
パイプラインのカスタマイズの基本を学習しました。 次に、使用する言語のパイプラインのカスタマイズの詳細を確認することをお勧めします。
または、CI パイプラインを CI/CD パイプラインに拡張するには、環境にアプリをデプロイする手順を含むデプロイ ジョブを含めます。
このガイドのトピックの詳細については、「ジョブ、タスク、タスクのカタログ、変数、トリガー、またはトラブルシューティング」を参照してください。
YAML パイプラインで他にできることについては、YAML スキーマのリファレンスを参照してください。