タスクの種類 & 使用状況

Azure Pipelines | Azure DevOps Server 2020 | Azure DevOps Server 2019 | TFS 2018 - TFS 2015

注意

Microsoft Team Foundation Server (TFS) 2018 以前のバージョンでは、ビルドとリリースの "パイプライン" は "定義"、"実行" は "ビルド"、"サービス接続" は "サービス エンドポイント"、"ステージ" は "環境"、"ジョブ" は "フェーズ" と呼ばれます。

タスク は、パイプラインでオートメーションを定義するためのビルディングブロックです。 タスクは、一連の入力で抽象化された、パッケージ化されたスクリプトまたはプロシージャです。

パイプラインにタスクを追加すると、一連の 要求 がパイプラインに追加されることもあります。 要求によって、タスクを実行するために エージェント にインストールする必要がある前提条件が定義されます。 ビルドまたは配置を実行すると、これらの要求を満たすエージェントが選択されます。

ジョブを実行すると、すべてのタスクが順番に実行されます。 複数のエージェントで同じタスクのセットを並列実行するか、エージェントを使用せずにいくつかのタスクを実行するには、「 ジョブ」を参照してください。

既定では、すべてのタスクは同じコンテキストで実行されます。 ホスト 上にある場合も、 ジョブコンテナー内にある場合も同様です。 必要に応じて、 ステップターゲット を使用して、個々のタスクのコンテキストを制御することもできます。

Yaml スキーマを使用してタスクのプロパティを指定する方法について説明します。

ジョブを実行すると、すべてのタスクが1つずつ、エージェントで順番に実行されます。 複数のエージェントで同じタスクのセットを並列実行するか、エージェントを使用せずにいくつかのタスクを実行するには、「 ジョブ」を参照してください。

カスタムタスク

基本的なビルドと配置のシナリオを実現するため の組み込みタスク がいくつか用意されています。 また 、独自のカスタムタスクを作成するためのガイダンスも提供しています。

さらに、 Visual Studio Marketplace には多数の拡張機能が用意されています。サブスクリプションまたはコレクションにインストールすると、タスクカタログが1つ以上のタスクで拡張されます。 さらに、Azure Pipelines または TFS にタスクを追加するための独自の カスタム拡張機能 を作成することもできます。

YAML パイプラインでは、タスクを名前で参照します。 名前がボックス内のタスクとカスタムタスクの両方に一致する場合は、インボックスタスクが優先されます。 このリスクを回避するには、タスク GUID またはカスタムタスクの完全修飾名を使用します。

steps:
- task: myPublisherId.myExtensionId.myContributionId.myTaskName@1 #format example
- task: qetza.replacetokens.replacetokens-task.replacetokens@3 #working example

とを検索するには myPublisherId myExtensionId 、marketplace のタスクの [ 取得 ] を選択します。 URL 文字列のの後の値 itemName は、 myPublisherIdmyExtensionId です。 また、タスクを リリースパイプライン に追加し、タスクを編集するときに [ Yaml の表示 ] を選択して、完全修飾名を検索することもできます。

タスクのバージョン

タスクはバージョン管理されており、パイプラインで使用されるタスクのメジャーバージョンを指定する必要があります。 これは、新しいバージョンのタスクがリリースされたときの問題を回避するのに役立ちます。 タスクには通常下位互換性がありますが、シナリオによっては、タスクが自動的に更新されるときに予期しないエラーが発生することがあります。

新しいマイナーバージョン (1.2 から1.3 など) がリリースされると、ビルドまたはリリースによって自動的に新しいバージョンが使用されます。 ただし、新しいメジャーバージョン (2.0 など) がリリースされた場合、ビルドまたはリリースでは、パイプラインを編集して新しいメジャーバージョンに手動で変更するまで、指定したメジャーバージョンが引き続き使用されます。 ビルドまたはリリースのログには、新しいメジャーバージョンが使用可能であることを示すアラートが含まれます。

記号の後にタスクの完全なバージョン番号 (例:) を指定することで、使用するマイナーバージョンを設定でき @ GoTool@0.3.1 ます。 組織に存在するタスクのバージョンのみを使用できます。

YAML では、タスク名にを使用してメジャーバージョンを指定し @ ます。 たとえば、タスクのバージョン2にピン留めするには、次のようにし PublishTestResults ます。

steps:
- task: PublishTestResults@2

YAML パイプラインは TFS では使用できません。

タスク制御オプション

各タスクには、いくつかの 制御オプション が用意されています。

コントロールオプションは、セクションのキーとして使用でき task ます。

- task: string  # reference to a task and version, e.g. "VSBuild@1"
  condition: expression     # see below
  continueOnError: boolean  # 'true' if future steps should run even if this step fails; defaults to 'false'
  enabled: boolean          # whether or not to run this step; defaults to 'true'
  timeoutInMinutes: number  # how long to wait before timing out the task
  target: string            # 'host' or the name of a container resource to target

タイムアウト期間は、タスクの実行が開始されると開始されます。 タスクがキューに登録されている時間や、エージェントを待機している時間は含まれません。

この YAML で PublishTestResults@2 は、 succeededOrFailed () 条件が原因で、前の手順が失敗した場合でもが実行されます。

steps:
- task: UsePythonVersion@0
  inputs:
    versionSpec: '3.7'
    architecture: 'x64'
- task: PublishTestResults@2
  inputs:
    testResultsFiles: "**/TEST-*.xml"
  condition: succeededOrFailed()

注意

完全なスキーマについては、「」task yaml スキーマを参照してください。

条件

  • 以前のすべての依存関係が成功した場合のみ。 これは、YAML に条件が設定されていない場合の既定値です。

  • 以前の依存関係が失敗した場合でも、実行が取り消された場合を除きます。 succeededOrFailed()この条件には、YAML でを使用します。

  • 以前の依存関係が失敗した場合でも、実行が取り消された場合でも。 always()この条件には、YAML でを使用します。

  • 以前の依存関係が失敗した場合のみ。 failed()この条件には、YAML でを使用します。

ステップターゲット

タスクは、エージェントホストまたはコンテナーのいずれかである実行コンテキストで実行されます。 個々のステップでは、を指定することによってコンテキストをオーバーライドでき target ます。 使用可能なオプションは、 host エージェントホストとパイプラインで定義されているすべてのコンテナーを対象とする単語です。 次に例を示します。

resources:
  containers:
  - container: pycontainer
    image: python:3.8

steps:
- task: SampleTask@1
  target: host
- task: AnotherTask@1
  target: pycontainer

ここで、は SampleTask ホスト上で実行さ AnotherTask れ、コンテナーで実行されます。

YAML パイプラインは TFS では使用できません。

ビルドツールインストーラー (Azure Pipelines)

ツールインストーラーを使用すると、ビルドパイプラインで依存関係をインストールおよび制御できます。 具体的には次のことができます。

  • CI ビルドに対して、すぐに ( Microsoft がホストするエージェントでも) ツールまたはランタイムをインストールします。

  • Node.js などの複数のバージョンの依存関係に対して、アプリまたはライブラリを検証します。

たとえば、複数のバージョンの Node.js に対してアプリを実行および検証するようにビルドパイプラインを設定できます。

例: 複数のバージョンの Node.js でアプリをテストおよび検証する

次の内容を使用して、プロジェクトの基本ディレクトリに azure-pipelines ファイルを作成します。

pool:
  vmImage: 'Ubuntu 16.04'

steps:
# Node install
- task: NodeTool@0
  displayName: Node install
  inputs:
    versionSpec: '6.x' # The version we're installing
# Write the installed version to the command line
- script: which node

新しいビルドパイプラインを作成 して実行します。 ビルドの実行方法を確認します。 Node.js ツールインストーラーによって、Node.js バージョンがまだエージェントにない場合はダウンロードされます。 コマンドラインスクリプトによって、ディスク上の Node.js バージョンの場所がログに記録されます。

YAML パイプラインは TFS では使用できません。

ツールインストーラーのタスク

ツールのインストーラータスクの一覧については、「 ツールインストーラーのタスク」を参照してください。

無効化 (インボックスと Marketplace のタスクを)

[組織の設定] ページで、Marketplace タスク、インボックスタスク、またはその両方を無効にすることができます。 Marketplace のタスクを無効にすると、パイプラインの セキュリティを強化 するのに役立ちます。 インボックスと Marketplace の両方のタスクを無効にすると、を使用してインストールしたタスクだけ tfx が使用できるようになります。

ヘルプとサポート