次の方法で共有

Azure Pipelines での YAML の機能強化 - Sprint 142 Update

  • [アーティクル]

Azure DevOps の Sprint 142 Update では、 ビルドにカスタム カウンターを追加する、 プル要求用にビルドするブランチを指定する、テンプレートをインラインで 使用するなど、YAML にいくつかの機能強化が行われています。 また、すべてのユーザーの新しいナビゲーションを有効にし、ダーク テーマを導入し、Azure Boardsのリンクと添付ファイルのエクスペリエンスを改善しました。

詳細については、以下の 機能 の一覧を参照してください。

機能

全般:

Azure Boards:

Azure Repos:

Azure Pipelines:

Azure Test Plans:

Azure Artifacts:

Wiki:

[Administration:

全般

すべてのユーザーに対して新しいナビゲーションがオンになっている

すべてのユーザーに対して新しいナビゲーションを有効にしました。 これは、新製品の設計を展開する際の大きなマイルストーンです。 このリリースでは、すべてのユーザーを新しいナビゲーション モデルに移行していますが、ユーザーは 2019 年 1 月 16 日まで古いナビゲーションをオプトアウトして使用できます。 オプトアウトするには、すべてのページの右上にあるアバターの下にあるメニューから [ プレビュー機能 ] を選択します。

詳細については、 ナビゲーション更新 のブログ投稿を参照してください。

ダーク テーマ

長年の機能要求の 1 つは、ダーク テーマを提供することです。 これが新しいナビゲーションの一部として利用可能になったことをお知らせします。 ダーク テーマをオンにするには、すべてのページの右上にあるアバターの下にあるメニューから [ テーマ ] を選択します。

ダーク テーマ

Azure Boards

豊富な作業項目の添付ファイルを使用して参照資料を整理する

作業項目にファイルを添付すると、自分とチームは参照資料を一元化して、必要なときに常に近づけることができます。 作業項目フォーム上の任意の場所にファイルをドラッグ アンド ドロップするだけで、新しい添付ファイルを簡単に追加できるようになりました。 引き続き添付ファイルを一覧として表示したり、グリッド ビューに切り替えてサムネイル プレビューを表示したりできます。 ファイルをダブルクリックしてプレビューを開き、必要な情報をすばやく見つけられるように順番に移動します。

作業項目の添付ファイル

組織全体の作業項目をリンクして依存関係を管理する

関連する作業または依存する作業をリンクすると、追跡する作業に対するより広範なコンテキストが得られ、他のチームとの依存関係を管理するのに役立ちます。 リモート作業のリンクを使用して、社内の組織全体の作業を追跡できるようになりました。 既存の作業項目の URL をコピーし、別の作業項目に移動し、次の 3 つの新しいリンクの種類のいずれかを使用してリンクを作成するだけです。 Azure Boardsでの追跡可能性の詳細については、作業項目のリンクに関するドキュメントを参照してください。

Note

アクセス許可は、両方の Azure DevOps 組織で尊重されます。両方とも同じ Azure AD テナントによってサポートされている必要があります。

リモート リンク

複数の依存関係の管理を開始したら、クエリの新しい [リモート リンク数] フィールドを使用して、プロジェクトにリモート依存関係がある作業項目を一覧表示するか、依存関係トラッカー拡張機能のインストールを検討します。 この拡張機能は、スケールのニーズを満たすために Microsoft の Windows グループによって作成され、依存関係の豊富な階層とグラフィカルな表現を表示するためのリモート リンクに基づいて構築されています。

以前は、作業項目のプレビュー ウィンドウがオフになっている場合、検索結果ページから作業項目を開くことができませんでした。 これにより、検索結果を掘り下げるのが困難になります。 作業項目のタイトルをクリックして、モーダル ウィンドウで作業項目を開くことができます。 この機能は UserVoice から優先されました。

Azure Repos

拡張機能の作成者は、現在のリポジトリに関するコンテキストに対してクエリを実行できます

バージョン管理拡張機能の作成者にとっての課題の 1 つは、名前、ID、URL など、ユーザーに表示されるリポジトリのコンテキストを取得することです。 これを支援するために、拡張機能にアクセスできるサービスとして VersionControlRepositoryService を追加しました。 これを使用すると、拡張機能の作成者は、Web UI 内の現在の Git リポジトリ コンテキストに関する情報を照会できます。 現在、getCurrentGitRepository() という 1 つのメソッドがあります。

  • Git リポジトリが選択されている場合は、リポジトリに関する基本的なデータ (名前、ID、URL) を含む GitRepository オブジェクトが返されます。
  • TFVC リポジトリが選択されている場合、またはサービスがAzure Repos ページの外部でアクセスされた場合は、null が返されます。

このサービスを使用する 拡張機能の例 を次に示します。

Azure Pipelines

ビルドにカスタム ビルド カウンターを追加する

ビルド カウンターは、ビルドに一意に番号を付け、ラベルを付ける方法を提供します。 以前は、$(rev:r) 特殊変数を使用してこれを実現できました。 ビルドを実行するたびに自動インクリメントされる独自のカウンター変数をビルド定義で定義できるようになりました。 これは、定義の [変数] タブで行います。 この新機能により、次の方法でより多くの機能が提供されます。

  • カスタム カウンターを定義し、そのシード値を設定できます。 たとえば、カウンターは 100 から開始できます。 $(rev:r) は常に 0 から始まります。
  • 独自のカスタム ロジックを使用してカウンターをリセットできます。 $(rev:r) はビルド番号の生成に関連付けられており、ビルド番号に新しいプレフィックスがある場合は常に自動リセットされます。
  • 定義ごとに複数のカウンターを定義できます。
  • ビルドの外部にあるカウンターの値に対してクエリを実行できます。 たとえば、カウンターを使用して、前回のリセット以降に実行されたビルドの数をカウントできます。

ビルド カウンターの詳細については、 ユーザー定義変数 に関するドキュメントを参照してください。

YAML を使用して pull request 用にビルドするブランチを指定する

YAML パイプラインでは、PR (pull request) 用にビルドするブランチを指定できます。 含めるブランチと除外するブランチを選択できます。 この機能は、以前は Web UI で使用できます。 YAML ファイルに移動すると、コードとしての構成ワークフローの一部になります。

PR トリガーの使用例を次に示します。

pr:
  branches:
    include:
    - features/*
    exclude:
    - features/experimental/*
  paths:
    include:
    - **/*.cs

steps:
- script: echo My PR build!

インラインで YAML テンプレート式を使用する

YAML テンプレートは、パイプラインの一部を再利用するための強力な方法です。 テンプレート式では、一般的なコードを考慮するだけでなく、値を変更し、含まれる YAML を制御できます。 これまで、テンプレート式は YAML 式の値全体を占める必要がありました。 式が ソリューション プロパティの値全体であるため、この例は機能します。

- task: msbuild@1
  inputs:
    solution: ${{ parameters.solution }}

次の例に示すように、制限を緩和し、インライン テンプレートを許可しました。

- script: echo The solution file is ${{ parameters.solution }}

パイプライン初期化ログを使用したトラブルシューティングの改善

パイプラインを実行する場合、Azure Pipelines では、パイプライン定義が正しいことを確認し、スケジュールするジョブを決定し、エージェントにジョブの実行を要求する必要があります。 これまで、このプロセスは完全に不透明であったため、問題が発生した場合、顧客が問題のトラブルシューティングを行うのはほとんど不可能でした。 パイプライン初期化ログと呼ばれる新しい種類のログが導入され、これらの詳細が表示されます。 完成したビルドで [ すべてのログのダウンロード ] オプションを選択すると、パイプライン初期化ログにアクセスできます。

YAML パイプラインの既定のリテンション期間

ユーザーが YAML パイプラインの保持ポリシーを構成する方法に取り組んでいます。 この新機能が利用できるようになるまで、すべての YAML ビルドの既定のリテンション期間が 30 日に増えました。多くのユーザーは、以前の 10 日間の既定のリテンション期間よりも長くビルドを維持したいと考えています。 新しいモデルが配置されるまで、YAML パイプラインのエディターで保持タブを削除しました。

Linux/ARM および Windows 32 ビット プラットフォーム上でビルドする

Azure Pipelines オープンソースクロスプラットフォーム エージェントは、64 ビット (x64) Windows、macOS、Linux で常にサポートされています。 このスプリントでは、 Linux/ARM と Windows/32 ビットの 2 つの新しいサポートされるプラットフォームが導入されています。 これらの新しいプラットフォームを使用すると、Linux/ARM マシンである Raspberry Pi などの、あまり一般的ではなく、それほど重要ではないプラットフォームを基に構築できます。

変数グループを複製する

変数グループの複製のサポートが追加されました。 変数グループをレプリケートし、いくつかの変数を更新するだけの場合は、変数を 1 つずつ追加する面倒なプロセスを実行する必要はありません。 これで、変数グループのコピーをすばやく作成し、値を適切に更新して、新しい変数グループとして保存できるようになりました。

変数グループを複製する

Note

シークレット変数の値は、変数グループを複製するときにコピーされません。 暗号化された変数を更新し、複製された変数グループを保存する必要があります。

すべてのリンクされたソースのコミットと作業項目に関するページを参照してください

追跡可能性の向上に向けた取り組みを継続し、パイプラインにリンクされているすべての成果物のコミットと作業項目の詳細をお客様が確認できるようになったことをお知らせします。 既定では、コミットと作業項目は、同じステージへの最後のデプロイと比較されます。 ただし、必要に応じて、他の以前のデプロイと比較できます。

リンクされたソース

Azure App Service 展開でサポートされているパッケージから実行する

Azure App Service配置タスク (4.*) バージョンでは、RunFromPackage (以前は RunFromZip と呼ばれる) がサポートされるようになりました。

App Serviceでは、msdeploy (別名 WebDeploy)、git、ARM など、ファイルをデプロイするためのさまざまな手法がサポートされています。 ただし、これらすべての手法には制限があります。 ファイルは wwwroot フォルダー (具体的には d:\home\site\wwwroot) の下に展開され、ランタイムはそこからファイルを実行します。

パッケージから実行すると、個々のファイルを wwwroot にコピーする展開手順はなくなりました。 代わりに、zip ファイルをポイントするだけで、zip は読み取り専用ファイル システムとして wwwroot にマウントされます。 これにはいくつかの利点があります。

  • ファイル コピー ロック問題のリスクを軽減します。
  • 運用環境のアプリにデプロイできます (再起動が必要です)。
  • アプリで実行されるファイルを確定できます。
  • Azure App Serviceデプロイのパフォーマンスが向上します。
  • 特に大規模な npm パッケージのツリーの JavaScript 関数の場合、コールド スタート時間を減らすことができます。

App Server Deploy タスクを使用して Linux コンテナーをデプロイする

Azure App Serviceデプロイ タスクの 4.* バージョンでは、独自のカスタム コンテナーを Linux 上のAzure Functionsにデプロイできるようになりました。

Azure Functionsの Linux ホスティング モデルは、Docker コンテナーに基づいており、アプリ固有の依存関係のパッケージ化と活用の点で柔軟性が向上します。 Linux 上の関数は、次の 2 つの異なるモードでホストできます。

  1. 組み込みのコンテナー イメージ: Function App コードを使用すると、コンテナー (組み込みイメージ モード) が Azure によって提供および管理されるため、Docker に関連する特定の知識は必要ありません。 これは、既存のバージョンの App Service 配置タスクでサポートされています。
  2. カスタム コンテナー イメージ:Linux 上の Azure Functions へのカスタム コンテナー イメージのデプロイをサポートするために、App Serviceデプロイ タスクが強化されました。 関数に特定の言語バージョンが必要な場合、または組み込みイメージ内に用意されていない特定の依存関係または構成が必要な場合は、Azure Pipelines を使用してカスタム イメージをビルドして Linux 上の Azure 関数にデプロイできます。

Azure Test Plans

デスクトップ アプリケーションの手動テストを実行する Azure Test Runner クライアント

Azure Test Runner (ATR) クライアントを使用して、デスクトップ アプリケーションの手動テストを実行できるようになりました。 これは、Microsoft Test Manager からAzure Test Plansに移行するのに役立ちます。 こちらの ガイダンスを参照してください。 ATR クライアントを使用すると、手動テストを実行し、各テスト ステップのテスト結果を記録できます。 また、スクリーンショット、画像アクション ログ、オーディオ ビデオ録画などのデータ収集機能もあります。 テスト時に問題が見つかった場合は、テスト ランナーを使用して、テスト ステップ、スクリーンショット、およびコメントがバグに自動的に含まれるバグを作成します。

ATR には、ランナーの 1 回限りのダウンロードとインストールが必要です。 次に示すように、[ デスクトップ アプリケーションの実行] を 選択します。

Azure Test Runner

Azure Test Runner のインストール

Azure Artifacts

パイプライン成果物のパブリック プレビュー

Azure Pipelines で使用するために設計された、拡張性の高い新しい成果物の種類である Pipeline Artifacts のパブリック プレビューをリリースします。 パイプライン成果物は、最近発表された ユニバーサル パッケージ 機能で使用されたのと同じテクノロジに基づいており、大規模なエンタープライズ クラス ビルドのビルド出力の格納にかかる時間を大幅に短縮できます。

Wiki

投稿アクセス許可を持つ Wiki としてコードを発行する

以前は、Git リポジトリに 対するリポジトリの作成 アクセス許可を持つユーザーのみが、コードを wiki として発行できました。 これにより、リポジトリ管理者または作成者は、Git リポジトリでホストされている Markdown ファイルを Wiki として発行する要求のボトルネックになりました。 これで、コード リポジトリに対する投稿アクセス許可がある場合は、コードを wiki として発行できます。

管理

PAT によって CAP が適用される

2017 年 2 月に 、Azure Active Directory 条件付きアクセス ポリシー (CAP) のサポートが発表されましたが、個人用アクセス トークンなどの代替認証メカニズムで CAP が適用されないという制限がありました。 このギャップを埋めたことをお知らせします。また、PAT、SSH キー、代替認証資格情報、OAuth を使用する場合、Azure DevOps は CAP IP フェンス ポリシーを受け入れることができるようになりました。 管理者は、この機能を利用するために何もする必要はありません。 既存のすべてのポリシーに自動的に適用されます。

次の手順

Note

これらの機能は、今後 2 ~ 3 週間にわたってロールアウトされます。

以下の新機能について読み、Azure DevOps に進んで自分で試してみてください。

Azure DevOps に移動する

フィードバックの提供方法

これらの機能についてご意見をお聞かせください。 フィードバック メニューを使用して、問題を報告したり、提案を提供したりします。

ご提案の送信

Stack Overflow のコミュニティからアドバイスや質問に回答してもらうこともできます。

よろしくお願いします。

Aaron Bjork