Azure DevOps Server 2019 リリース ノート

  • [アーティクル]

| Developer Communityシステム要件 | ライセンス条項 | DevOps ブログ | SHA-1 ハッシュ

この記事では、Azure DevOps Serverの最新リリースに関する情報を確認できます。

Azure DevOps Server展開のインストールまたはアップグレードの詳細については、「Azure DevOps Server要件」を参照してください。 Azure DevOps 製品をダウンロードするには、Azure DevOps Serverダウンロード ページを参照してください。

Azure DevOps Server 2020 への直接アップグレードは、Azure DevOps Server 2019 以降または Team Foundation Server 2015 以降でサポートされています。 TFS 展開が TFS 2010 以前の場合は、Azure DevOps Server 2019 にアップグレードする前にいくつかの中間手順を実行する必要があります。 詳細については、「 Azure DevOps をオンプレミスにインストールして構成する」を参照してください。

Azure DevOps Server 2019 から Azure DevOps Server 2020 への安全なアップグレード

Azure DevOps Server 2020 では、プロジェクト レベルの設定に基づいて動作する新しいパイプライン実行 (ビルド) 保持モデルが導入されています。

Azure DevOps Server 2020 では、パイプライン レベルの保持ポリシーに基づいて、ビルドの保持が異なる方法で処理されます。 特定のポリシー構成では、アップグレード後にパイプラインの実行が削除されます。 手動で保持されている、またはリリースによって保持されているパイプラインの実行は、アップグレード後に削除されません。

Azure DevOps Server 2019 から Azure DevOps Server 2020 に安全にアップグレードする方法の詳細については、ブログ記事を参照してください。

Azure DevOps Server 2019.0.1 パッチ 16 リリース日: 2023 年 11 月 14 日

Azure DevOps Server 2019 Update 1.2 の修正プログラムをリリースしました。これには、次の修正プログラムが含まれています。

  • シェル タスク引数パラメーター検証を有効にするの PowerShell タスクの許可される文字の一覧を拡張しました。

Note

このパッチの修正プログラムを実装するには、いくつかの手順に従ってタスクを手動で更新する必要があります。

修正プログラムをインストールする

重要

2023 年 9 月 12 日にパッチ 15 がリリースされた Azure Pipelines エージェントの更新プログラムをリリースしました。 パッチ 15 のリリース ノートで説明されているようにエージェントの更新プログラムをインストールしなかった場合は、Patch 16 をインストールする前にこれらの更新プログラムをインストールすることをお勧めします。 Patch 15 をインストールした後のエージェントの新しいバージョンは 3.225.0 になります。

TFX の構成

  1. プロジェクト コレクションへのタスクのアップロードに関するドキュメントの手順に従って、tfx-cli をインストールしてログインします。

TFX を使用してタスクを更新する

ファイル Sha-256 ハッシュ
Tasks20231103.zip 389BA66EEBC32622FB83402E21373CE20AE040F70461B9F9AF9EFCED5034D2E5
  1. Tasks20231103.zipをダウンロードして抽出します。
  2. 抽出されたファイルにディレクトリを変更します。
  3. 次のコマンドを実行してタスクをアップロードします。
tfx build tasks upload --task-zip-path AzureFileCopyV1.1.230.0.zip
tfx build tasks upload --task-zip-path AzureFileCopyV2.2.230.0.zip 
tfx build tasks upload --task-zip-path AzureFileCopyV3.3.230.0.zip 
tfx build tasks upload --task-zip-path AzureFileCopyV4.4.230.0.zip 
tfx build tasks upload --task-zip-path AzureFileCopyV5.5.230.0.zip 
tfx build tasks upload --task-zip-path BashV3.3.226.2.zip 
tfx build tasks upload --task-zip-path BatchScriptV1.1.226.0.zip 
tfx build tasks upload --task-zip-path PowerShellV2.2.230.0.zip 
tfx build tasks upload --task-zip-path SSHV0.0.226.1.zip 
tfx build tasks upload --task-zip-path WindowsMachineFileCopyV1.1.230.0.zip 
tfx build tasks upload --task-zip-path WindowsMachineFileCopyV2.2.230.0.zip

パイプラインの要件

新しい動作を使用するには、影響を受けるタスクを使用するパイプラインで変数 AZP_75787_ENABLE_NEW_LOGIC = true を設定する必要があります。

  • クラシックの場合:

    パイプラインの変数タブで変数を定義します。

  • YAML の例:

variables: 
- name: AZP_75787_ENABLE_NEW_LOGIC 
  value: true

Azure DevOps Server 2019.0.1 パッチ 15 リリース日: 2023 年 9 月 12 日

以下を修正するAzure DevOps Server 2019.0.1 用のパッチをリリースしました。

  • CVE-2023-33136: リモート コード実行の脆弱性Azure DevOps Server。
  • CVE-2023-38155: Azure DevOps Serverと Team Foundation Server の特権昇格の脆弱性。

重要

修正プログラムを運用環境に適用する前に、テスト環境にパッチをデプロイし、環境のパイプラインが期待どおりに動作することを確認してください。

Note

このパッチの修正プログラムを実装するには、いくつかの手順に従ってエージェントとタスクを手動で更新する必要があります。

修正プログラムをインストールする

  1. Azure DevOps Server 2019.0.1 Patch 15 をダウンロードしてインストールします。

Azure Pipelines エージェントを更新する

  1. エージェントのダウンロード元: https://github.com/microsoft/azure-pipelines-agent/releases/tag/v3.225.0 - Agent_20230825.zip
  2. セルフホステッド Windows エージェントのドキュメントに記載されている手順を使用して、エージェントを展開します。  

Note

エージェントがダウングレードされないようにするには、AZP_AGENT_DOWNGRADE_DISABLEDを "true" に設定する必要があります。 Windows では、管理コマンド プロンプトで次のコマンドを使用し、その後に再起動することができます。 setx AZP_AGENT_DOWNGRADE_DISABLED true /M

TFX の構成

  1. プロジェクト コレクションへのタスクのアップロードに関するドキュメントの手順に従って、tfx-cli をインストールしてログインします。

TFX を使用してタスクを更新する

  1. Tasks_20230825.zipをダウンロードして抽出します。
  2. 抽出されたファイルにディレクトリを変更します。
  3. 次のコマンドを実行してタスクをアップロードします。
tfx build tasks upload --task-zip-path AzureFileCopyV1.1.226.3.zip 
tfx build tasks upload --task-zip-path AzureFileCopyV2.2.226.2.zip 
tfx build tasks upload --task-zip-path AzureFileCopyV3.3.226.2.zip 
tfx build tasks upload --task-zip-path AzureFileCopyV4.4.226.2.zip 
tfx build tasks upload --task-zip-path AzureFileCopyV5.5.226.2.zip 
tfx build tasks upload --task-zip-path BashV3.3.226.2.zip 
tfx build tasks upload --task-zip-path BatchScriptV1.1.226.0.zip 
tfx build tasks upload --task-zip-path PowerShellV2.2.226.1.zip 
tfx build tasks upload --task-zip-path SSHV0.0.226.1.zip 
tfx build tasks upload --task-zip-path WindowsMachineFileCopyV1.1.226.2.zip 
tfx build tasks upload --task-zip-path WindowsMachineFileCopyV2.2.226.2.zip

パイプラインの要件

新しい動作を使用するには、影響を受けるタスクを使用するパイプラインで変数 AZP_75787_ENABLE_NEW_LOGIC = true を設定する必要があります。

  • クラシックの場合:

    パイプラインの変数タブで変数を定義します。

  • YAML の例:

variables: 
- name: AZP_75787_ENABLE_NEW_LOGIC 
  value: true

Azure DevOps Server 2019.0.1 パッチ 14 リリース日: 2022 年 8 月 8 日

以下を修正するAzure DevOps Server 2019.0.1 用のパッチをリリースしました。

  • CVE-2023-36869: Azure DevOps Serverスプーフィングの脆弱性。

Azure DevOps Server 2019.0.1 パッチ 13 リリース日: 2022 年 5 月 17 日

以下を修正するAzure DevOps Server 2019.0.1 用のパッチをリリースしました。

  • ユーザーの Active Directory アカウントが無効になった後、すべての個人用アクセス トークンを取り消します。

Azure DevOps Server 2019.0.1 パッチ 12 リリース日: 2022 年 1 月 26 日

以下を修正するAzure DevOps Server 2019.0.1 用のパッチをリリースしました。

  • log4j バイナリから jndilookup クラスを削除することにより、Elasticsearch の脆弱性に対処しました。

インストール手順

  1. パッチ 12 を使用してサーバーをアップグレードします。
  2. HKLM:\Software\Elasticsearch\Version でレジストリ値を確認します。 そこにレジストリ値がない場合は、文字列値を追加し、Version を 5.4.1 (Name = Version、Value = 5.4.1) に設定します。
  3. readme ファイルに指定されているように更新コマンド PS C:\Program Files\{TFS Version Folder}\Search\zip> .\Configure-TFSSearch.ps1 -Operation update を実行します。 次のような警告が返される場合があります: "リモート サーバー に接続できません"。 更新プログラムによって再試行が実行されている場合は、それが完了するまで、ウィンドウを閉じないでください。

注意

Azure DevOps Server と Elasticsearch が異なるマシンにインストールされている場合は、次の手順に従います。

  1. パッチ 12 を使用してサーバーをアップグレードします。
  2. HKLM:\Software\Elasticsearch\Version でレジストリ値を確認します。 そこにレジストリ値がない場合は、文字列値を追加し、Version を 5.4.1 (Name = Version、Value = 5.4.1) に設定します。
  3. C:\Program Files\{TFS Version Folder}\Search\zip にある zip という名前のフォルダーの内容を Elasticsearch リモート ファイル フォルダーにコピーします。
  4. Elasticsearch サーバー マシンで Configure-TFSSearch.ps1 -Operation update を実行します。

SHA-256 ハッシュ: 96C7AF3E3ED67C76451BA228427B3C0738EEB4A5835B6A91EBD3205A54C384D7

Azure DevOps Server 2019.0.1 パッチ 11 リリース日: 2021 年 8 月 10 日

以下を修正するAzure DevOps Server 2019.0.1 用のパッチをリリースしました。

  • ビルド定義 UI エラーを修正しました。

Azure DevOps Server 2019.0.1 パッチ 10 リリース日: 2021 年 4 月 13 日

以下を修正するAzure DevOps Server 2019.0.1 用のパッチをリリースしました。

パッチ 10 を適用するには、タスクをインストール AzureResourceGroupDeploymentV2 する必要があります。

AzureResourceGroupDeploymentV2 タスクのインストール

Note

以下に説明する手順はすべて、Windows コンピューター上で実行する必要があります。

インストール

  1. AzureResourceGroupDeploymentV2.zip パッケージをコンピューター上の新しいフォルダーに展開します。 例: AzureResourceGroupDeploymentV2。

  2. ご利用のコンピューターに合わせて、Node.js 14.15.1 と npm (Node.js ダウンロードに含まれています) をダウンロードしてインストールします。

  3. 管理者モードでコマンド プロンプトを開き、次のコマンドを実行して tfx-cli をインストールします。

npm install -g tfx-cli

  1. "フル アクセス" 特権で個人用アクセス トークンを作成し、それをコピーします。 この個人用アクセス トークンは、tfx login コマンドの実行時に使用されます。

  2. コマンド プロンプトから次を実行します。 プロンプトが表示されたら、サービス URL と個人用アクセス トークンを入力します。

~$ tfx login
Copyright Microsoft Corporation

> Service URL: {url}
> Personal access token: xxxxxxxxxxxx
Logged in successfully
  1. 次のコマンドを実行して、サーバー上にタスクをアップロードします。 手順 1 で抽出した .zip ファイルのパスを使用します。
  ~$ tfx build tasks upload --task-path *<Path of the extracted package>*

Azure DevOps Server 2019.0.1 Patch 9 リリース日: 2020 年 12 月 8 日

Azure DevOps Server 2019.0.1 の修正プログラムをリリースしました。この修正プログラムは次のとおりです。 詳細については、ブログ記事を参照してください。

  • CVE-2020-1325: Azure DevOps Serverスプーフィングの脆弱性
  • CVE-2020-17135: Azure DevOps Serverスプーフィングの脆弱性
  • CVE-2020-17145 : Azure DevOps Server と Team Foundation Server のスプーフィングの脆弱性
  • TFVC ですべての結果が処理されない問題を修正する

重要

このパッチをインストールする前に、以下の完全な手順をお読みください。

一般的なパッチのインストール

Azure DevOps Server 2019.0.1 をお持ちの場合は、Azure DevOps Server 2019.0.1 Patch 9 をインストールする必要があります。

インストールの確認

  • オプション 1: を実行 devops2019.0.1patch9.exe CheckInstalldevops2019.0.1patch9.exe は、上記のリンクからダウンロードされたファイルです。 コマンドの出力には、パッチがインストールされているか、インストールされていないことが示されます。

  • オプション 2: ファイルのバージョンを確認します。 [INSTALL_DIR]\Azure DevOps Server 2019\Application Tier\Web Services\bin\Microsoft.VisualStudio.Services.Feed.Server.dll Azure DevOps Server 2019 は既定で にc:\Program Files\Azure DevOps Server 2019インストールされます。 Azure DevOps Server 2019.0.1 Patch 9 をインストールすると、バージョンは 17.143.30723.4 になります。

AzurePowerShellV4 タスクのインストール

Note

以下に説明する手順はすべて、Windows コンピューター上で実行する必要があります。

前提条件

  1. Az モジュール Azure Powershell Azure PowerShellプライベート エージェント マシンにインストールします。

  2. AzurePowerShellV4 タスクを使用してパイプラインを作成します。 タスクに表示される 標準エラーの失敗 数は 1 つだけです。

インストール

  1. AzurePowerShellV4.zip パッケージを AzurePowerShellV4 という名前のフォルダーに抽出します。

  2. ご利用のコンピューターに合わせて、Node.js 14.15.1 と npm (Node.js ダウンロードに含まれています) をダウンロードしてインストールします。

  3. 管理者モードでコマンド プロンプトを開き、次のコマンドを実行して tfx-cli をインストールします。

npm install -g tfx-cli

  1. "フル アクセス" 特権で個人用アクセス トークンを作成し、それをコピーします。 この個人用アクセス トークンは、tfx login コマンドの実行時に使用されます。

  2. コマンド プロンプトから次を実行します。 プロンプトが表示されたら、サービス URL と個人用アクセス トークンを入力します。

~$ tfx login
Copyright Microsoft Corporation

> Service URL: {url}
> Personal access token: xxxxxxxxxxxx
Logged in successfully
  1. 次のコマンドを実行して、サーバー上にタスクをアップロードします。 抽出されたパッケージのパスは D:\tasks (1)\AzurePowerShellv4 になります。
  ~$ tfx build tasks upload --task-path *<Path of the extracted package>*

Azure DevOps Server 2019.0.1 Patch 8 リリース日: 2020 年 9 月 8 日

Azure DevOps Server 2019.0.1 のセキュリティ修正プログラムをリリースしました。この修正プログラムは次のとおりです。 詳細については、ブログ記事を参照してください。

  • DTS 1713492 - AD グループをセキュリティアクセス許可に追加する際の予期しない動作。

Azure DevOps Server 2019.0.1 Patch 7 リリース日: 2020 年 7 月 14 日

Azure DevOps Server 2019.0.1 のセキュリティ修正プログラムをリリースしました。この修正プログラムは次のとおりです。 詳細については、ブログ記事を参照してください。

  • CVE-2020-1326: クロスサイト スクリプティングの脆弱性
  • [その他の Git ソース] を選択すると、未承認のユーザーの接続が正しく表示されないビルド パイプライン。
  • XAML ビルド定義で継承を [オン] または [オフ] に変更するときに発生するエラーを修正しました。

Azure DevOps Server 2019.0.1 Patch 6 リリース日: 2020 年 6 月 10 日

Azure DevOps Server 2019.0.1 のセキュリティ修正プログラムをリリースしました。この修正プログラムは次のとおりです。 詳細については、ブログ記事を参照してください。

  • CVE-2020-1327: Azure DevOps Serverがユーザー入力をサニタイズすることを確認する
  • Azure DevOps での SSH での SHA2 のサポートの追加

Azure DevOps Server 2019.0.1 Patch 5 リリース日: 2020 年 3 月 10 日

Azure DevOps Server 2019.0.1 のセキュリティ修正プログラムをリリースしました。この修正プログラムは次のとおりです。 詳細については、ブログ記事を参照してください。

Azure DevOps Server 2019.0.1 Patch 3 リリース日: 2019 年 9 月 10 日

次のバグを修正する Azure DevOps Server 2019.0.1 用のセキュリティ修正プログラムをリリースしました。 詳細については、ブログ記事を参照してください。

  • CVE-2019-1305 : Repos でのクロス サイト スクリプティング (XSS) の脆弱性
  • CVE-2019-1306 : Wiki でのリモート コード実行の脆弱性

Azure DevOps Server 2019.0.1 Patch 2 リリース日: 2019 年 8 月 13 日

次のバグを修正する Azure DevOps Server 2019.0.1 用のセキュリティ修正プログラムをリリースしました。 詳細については、ブログ記事を参照してください。

  • サービス接続に情報を追加して、既定ですべてのパイプラインに対して承認されていることを明確にしました。

Azure DevOps Server 2019.0.1 パッチ 1 リリース日: 2019 年 7 月 9 日

次のバグを修正する Azure DevOps Server 2019.0.1 用のセキュリティ修正プログラムをリリースしました。 詳細については、ブログ記事を参照してください。

  • CVE-2019-1072 : 作業項目のトラッキング中のリモート コード実行の脆弱性
  • CVE-2019-1076 : プル要求にクロス サイト スクリプティング (XSS) の脆弱性

Azure DevOps Server 2019.0.1 リリース日: 2019 年 5 月 21 日

Azure DevOps Server 2019.0.1 はバグ修正のロールアップです。 これには、以前にリリースされたAzure DevOps Server 2019 パッチのすべての修正プログラムが含まれています。 Azure DevOps Server 2019.0.1 を直接インストールするか、Azure DevOps Server 2019 または Team Foundation Server 2012 以降からアップグレードできます。

Note

データ移行ツールは、このリリースから約 3 週間後Azure DevOps Server 2019.0.1 で使用できるようになります。 インポート用に現在サポートされているバージョンの一覧は、ここで確認できます。

このリリースには、次のバグの修正プログラムが含まれています。

Azure Boards

  • プランを構成するときに、"このプランのフィールド条件にエラーがあります"。 Developer Communityを通じて報告されます。
  • apiwitcontroller.executequery は、クエリが同じ列を複数回持つ場合に例外をスローします。
  • vso.work_full oauth スコープを使用するクライアント オブジェクト モデルでは、WorkItemServer.DownloadFile() は失敗します。
  • 作業項目フィールドから別のプロジェクトの別の作業項目フィールドに埋め込まれたイメージをコピーすると、破損したイメージが作成される場合があります。

Azure Repos

  • "TF401019: GitRepositoryNotFoundException"

Azure Pipelines

  • [Test Analytics] タブには、プレビューを示すstar (*) があります。この機能はプレビュー段階ではありません。
  • [ リリース ] タブで、アクセス許可を変更できるかどうかに関係なく、セキュリティを管理するアクションがすべてのユーザーに表示されるようになりました。
  • [リリース] ランディング ページで、ドラフトリリースの開始アクションで新しいリリースが作成されましたが、ドラフト リリースが開始されました。

Azure Test Plans

  • TestRuns と TestResults CompletedDate の 1 時間フィルターが細かすぎます。
  • [テスト ケース] 作業項目の種類では、"テスト ケース" という型をローカライズしないでください。
  • テスト ケースが MTM またはブラウザーに表示されません。
  • テスト プランから自動テストを実行すると、"検証ステージ: 関連付けられたリリース パイプラインでリリースをトリガーするアクセス許可がありません" というエラーが表示されます。 Developer Communityを通じて報告されます。
  • テスト ケースの削除 API を使用すると、テスト ケースを他のプロジェクトから削除できます。 Developer Communityを通じて報告されます。
  • テスト ランナーで作業項目リンクをクリックすると、既定のブラウザーではなく、テスト ランナー内で作業項目の URL が開きます。
  • テスト ランナーからサインアウトしたユーザーのテスト ケースの状態は更新されません。
  • ユーザー名と電子メール アドレスは、テスト ランナーのユーザー ドロップダウンには表示されません。

Azure Artifacts

  • 上へ移動 および 下へ移動 はアップストリームではローカライズされません。

分析

  • 分析レポートでは、モデルが実際に完了する前に "準備完了" としてマークされているため、不完全なデータが表示される場合があります。
  • 速度、バーンダウン、バーンアップウィジェットには、異なるタイムゾーンのユーザーに対して異なる計画作業が表示されます。
  • メンテナンス中に Analytics データ インジェストに保留が設定され、古いレポートが発生する可能性があります。

全般

  • 十分なスペースがない場合、IEでは左側のナビゲーション項目が絞られます。

管理

  • 問題のデバッグに役立つ追加のログ記録がコレクションのアップグレードに追加されました。
  • TfsConfig offlineDetach が失敗した場合、エラー メッセージは操作できません。
  • TfsJobAgent サービスがクラッシュします。
  • 構成の完了後、Search 拡張機能はインストールされません。
  • 構成 DB が破損すると、管理コンソールが応答しなくなります。
  • サービス フックで通知が正しく処理されない場合があります。
  • コード検索のインデックス作成は、Search の構成後に開始されません。
  • 検索ページの結果には、未割り当て文字列があります。

このリリースには、次の更新プログラムが含まれています。

Visual Studio テスト タスクでの Visual Studio 2019 (VS2019) のサポート

パイプラインの Visual Studio テスト タスクに Visual Studio 2019 のサポートを追加しました。 Visual Studio 2019 のテスト プラットフォームを使用してテストを実行するには、[テスト プラットフォームのバージョン] ドロップダウンから [最新 ] または [ Visual Studio 2019 ] オプションを選択します。

[テスト プラットフォームのバージョン] ドロップダウン リストが選択され、[最新の Visual Studio 2019] オプションが選択されていることを示す [実行オプション] セクションのスクリーンショット。

Azure DevOps Server 2019 Patch 2 リリース日: 2019 年 5 月 14 日

次のバグを修正するAzure DevOps Server 2019 のセキュリティ修正プログラムをリリースしました。 詳細については、ブログ記事を参照してください。

  • CVE-2019-0872 : Test Plans でのクロス サイト スクリプティング (XSS) の脆弱性
  • CVE-2019-0971 : Repos API での情報漏えいの脆弱性
  • CVE-2019-0979 : ユーザー ハブでのクロス サイト スクリプティング (XSS) の脆弱性

Azure DevOps Server 2019 Patch 1 リリース日: 2019 年 4 月 9 日

次のバグを修正するAzure DevOps Server 2019 のセキュリティ修正プログラムをリリースしました。 詳細については、ブログ記事を参照してください。

  • CVE-2019-0857: Wiki のスプーフィングの脆弱性
  • CVE-2019-0866 : Pipelines でのリモート コード実行の脆弱性
  • CVE-2019-0867 : Pipelines でのクロス サイト スクリプティング (XSS) の脆弱性
  • CVE-2019-0868 : Pipelines でのクロス サイト スクリプティング (XSS) の脆弱性
  • CVE-2019-0869: パイプラインでの HTML インジェクションの脆弱性
  • CVE-2019-0870 : Pipelines でのクロス サイト スクリプティング (XSS) の脆弱性
  • CVE-2019-0871 : Pipelines でのクロス サイト スクリプティング (XSS) の脆弱性
  • CVE-2019-0874: パイプラインでのクロス サイト スクリプティング (XSS) の脆弱性
  • CVE-2019-0875: Boards の特権の昇格の脆弱性

Azure DevOps Server 2019 リリース日: 2019 年 3 月 5 日

Note

データ移行ツールは、このリリースから約 3 週間後にAzure DevOps Server 2019 で使用できるようになります。 インポート用に現在サポートされているバージョンの一覧は、ここで確認できます。

RC2 リリース日: 2019 年 1 月 22 日

Azure DevOps Server 2019 RC2 の新機能の概要

RC2 に次の機能が追加されました。

RC1 リリース日: 2018 年 11 月 19 日

Azure DevOps Server 2019 RC1 の新機能の概要

Azure DevOps Server 2019 では、新しいナビゲーション エクスペリエンスと多くの新機能が導入されています。 主な特徴:

個々のセクションに移動して、新機能を確認することもできます。

全般

Azure DevOps Serverの発表

9 月 10 日に、Visual Studio Team Services と Team Foundation Server の進化として Azure DevOps を発表しました。 Azure DevOps Server 2019 は、この新しいブランドで初めてのオンプレミス リリースです。 詳細については、 ブログ記事を参照してください。

新しいナビゲーション エクスペリエンス

ユーザー エクスペリエンスを最新化するための新しいナビゲーションが導入されています。 この新しいナビゲーションは Azure DevOps サービスにロールアウトされ、Azure DevOps Server 2019 で使用できるようになりました。 詳細については 、ブログ を参照してください。

新しいナビゲーション

Artifacts と Release Management Deployment Pipeline Licensing の変更

ユーザーからのフィードバックに基づき、Azure DevOps Server 2019 でライセンスに 2 つの重要な変更を加えます。 まず、Artifacts を使用するために Artifact 拡張機能を購入する必要がなくなります。 これで、Artifacts ライセンスの使用が Basic ライセンスに含まれるようになります。 Basic ライセンスが割り当てられているすべてのユーザーは、成果物を使用できるようになります。 第 2 に、お客様はデプロイ パイプラインRelease Management購入する必要がなくなりました。 ビルド パイプラインと同様に、Release Management デプロイ パイプラインが Azure DevOps Server 2019 に含まれるようになりました。

Azure SQL データベースのサポート

Azure で Azure DevOps 2019 を実行するエクスペリエンスを簡略化するために、Azure SQL Database (General Purpose S3 以降) のサポートを有効にしました。 これにより、広範な バックアップ機能 と スケーリング オプション を利用して、ニーズに合わせてサービスを実行する管理オーバーヘッドを軽減できます。 待機時間を短く保つために、ホスト VM はデータベースと同じ Azure リージョンに配置する必要があることに注意してください。 詳細については、 ドキュメント をご覧ください。

今後のバージョン & クライアント オブジェクト モデルの SOAP API をテストする作業項目

Azure DevOps Server 2019 では、作業項目追跡 SOAP API とクライアント オブジェクト モデルが引き続きサポートされます。 ただし、今後のバージョンのAzure DevOps Serverでは非推奨としてマークされます。 詳細については、 こちらのドキュメントを参照してください。

新しいコレクションの継承を処理する

プロセスの継承が新しいコレクションで使用できるようになりました。 ユーザーは、新しいコレクションを作成するときに、プロセス モデルに関して良心的な決定を行う必要があります。 継承モデルの概要と、それが XML とどのように異なるかについての ドキュメント を参照してください。

プロセスの継承

検索の重要性を理解し、製品ヘッダーの展開された検索ボックスを取り戻しています。 さらに、Azure DevOps の任意のサービス ページで [/] をクリックするだけで、検索ボックスを呼び出すようになりました。

既定の検索ボックスを次に示します。

既定の検索ボックス

"/" を入力すると、展開された検索ボックスが表示されます。

展開された検索ボックス

自分の作業ポップアップ

私たちが紹介する新機能は、 私の仕事 のポップアップです。 製品の一部にいて、別の部分からの情報が必要な場合は、コンテキストを失いたくないというフィードバックを受け取っています。 この新機能を使用すると、製品のどこからでもこのポップアップにアクセスでき、作業項目、pull request、すべてのお気に入りなど、重要な情報をすばやく確認できます。 この新しいポップアップを使用すると、Repos でコード内に移動し、次に作業する作業項目をすばやくチェックする場合は、ポップアップをクリックして割り当てられた作業項目を表示し、次の項目を選択するだけです。

次に、自分に割り当てられている 作業 項目を示す [自分の作業] ポップアップを表示します。

自分の作業ポップアップ

ここでは、自分に割り当てられている PR を示す 2 番目のピボットを確認できます。 ポップアップには、さらに多くの pull request を表示するための 1 回のクリック アクセスもあります。

マイ ワーク ポップアップ PR

ここでは、最後のピボットを確認できます。これは、お気に入りのすべてです。 これには、お気に入りのチーム、ダッシュボード、ボード、バックログ、クエリ、リポジトリが含まれます。

作業ポップアップのお気に入り

Boards

コードに GitHub Enterprise を使用し、豊富なプロジェクト管理機能を必要とする Teams は、リポジトリをAzure Boardsと統合できるようになりました。 GitHub とAzure Boardsを接続することで、バックログ、ボード、スプリント計画ツール、複数の作業項目の種類などのすべての機能を取得でき、GitHub の開発者ワークフローと統合されたワークフローを引き続き使用できます。

コミットと pull request を作業項目にリンクするのは簡単です。 次の構文を使用して作業項目に言及します。

AB#{work item ID}

コミット メッセージ、pull request タイトル、または pull request の説明に作業項目をメンションすると、その成果物へのリンクが作成Azure Boards。 たとえば、次のようなコミット メッセージを考えてみましょう。

Adds support for deleting connections. Fixes AB#20.

これにより、作業項目 #20 から GitHub のコミットへのリンクが作成され、作業項目の [開発] セクションに表示されます。 ​

[開発] セクションが強調表示されている Azure DevOps のスクリーンショット。

"fix"、"fixs"、または "fixed" という単語が作業項目メンションの前にある場合 (上記のように)、コミットが既定のブランチにマージされると、作業項目は完了した状態に移動されます。

Azure Pipelines を使用して GitHub でコードをビルドしているチームには、ビルドの概要に GitHub コミットにリンクされている作業項目も表示されます。

新しい作業項目ハブ

作業項目ハブは、作業項目のホームとして機能する新しいハブです。 ここでは、作業項目の多くの異なるリスト ビューを使用して、対象を絞り込みます。 [ 自分に割り当て済み] を 表示すると、自分に割り当てられているすべての作業をすばやく確認したり、[ 最近更新 された] を表示したりできます。これにより、最近更新されたプロジェクト内のすべての作業項目が表示されます。 すべてのリスト オプションを次に示します。

作業項目ハブ

リストをさらに絞り込む場合は、型、割り当て先、状態、領域、タグ、キーワード (keyword)でフィルター処理できます。 目的のリスト ビューを作成したら、列のヘッダーをクリックするだけで作業項目を並べ替えることができます。 1 つの列が狭すぎて列の完全な内容を表示できない場合は、ヘッダー領域の列のサイズを簡単に変更できます。 これらのエクスペリエンスを次に示します。

作業項目ハブの一覧

新しいボード、バックログ、スプリント ハブ

Backlogs ハブは、ユーザー エクスペリエンスを向上させるために 3 つの異なるハブに分割されました。 強力ですが、古い Backlogs ハブには多くの機能が搭載されていました。 多くの場合、ユーザーが探していた機能を見つけるのが困難になりました。 この問題に対処するために、Backlogs ハブを次のように分割しました。

  • Backlogs ハブには、プロジェクトのバックログだけが含まれるようになりました。 バックログは、チームの作業の優先順位付けされた一覧です。 バックログには、作業項目階層、予測、新しいスプリント計画エクスペリエンスなどの計画ツールが用意されています。
  • 新しい Boards ハブには、プロジェクトのすべてのかんばんボードがあります。 ボードは、状態とフローを伝えるために使用されます。 カード (作業項目) は、チームによって定義された列を通じて、ボード全体で左から右に移動します。
  • 新しい Sprints ハブには、作業の増分を計画および実行するために使用される機能があります。 各スプリントには、スプリント バックログ、タスクボード、チームの容量を管理および設定するためのビューが含まれています。

Boards ハブ

新しいクエリ ハブ

新しいクエリ ハブでは、古いハブからの既存のクエリ機能の多くがよりモダンな外観で合理化され、重要なクエリに簡単にアクセスできる新しい機能が提供されます。 新しいエクスペリエンスのハイライトには、次のようなものがあります。

  • 情報によって最後に変更されたディレクトリ ページとクエリを検索する機能
  • 重要なクエリ グループをブックマークするためのフォルダーの一意の URL を持つ階層リンク
  • 結果ページからお気に入りのクエリにすばやくアクセスする

これらのエキサイティングな更新プログラムの詳細については、 DevOps ブログを参照してください。

作業項目を別のプロジェクトに移動し、作業項目の種類を変更する

これで、作業項目の種類を変更したり、プロジェクト コレクション内の別のプロジェクトに作業項目を移動したりできます。 これらの機能を使用するには、データ ウェアハウスが無効になっている必要があります。 データ ウェアハウスが無効になっているときは、Analytics サービスを使ってレポートのニーズをサポートできます。 データ ウェアハウスを無効にする方法の詳細については、「データ ウェアハウスとキューブを無効にする」を参照してください。

スプリント計画機能

新しいスプリント計画機能は、スプリント計画エクスペリエンスの迅速化と向上に役立ちます。

  • 次のスプリントを作成するか、 Sprints ハブから直接既存のスプリント スケジュールをサブスクライブします。
  • バックログの新しい [計画 ] ウィンドウを使用して、作業項目を将来のスプリントにドラッグ アンド ドロップします。 [ 計画 ] ウィンドウには、スプリント日付、作業項目数、計画作業が含まれます。
  • タスクボードの上部に要件を追加するか、クイック作成を使用して、スプリント バックログで選択した上、下、または行に追加します。
  • 担当者、作業項目の種類、状態、タグのフィルターを使用して、ニーズに合わせてビューを調整します。

スプリント計画

新しいディレクトリ ページ

バックログ、ボード、スプリントを含むすべての新しいハブには、次のセクションで整理された新しいディレクトリ ページが追加されました。

  • 中断した場所に進む この新しいセクションでは、最後の (ボード |バックログ |スプリント) をオンにしていました。
  • お気に入り すべてのチームでお気に入りのボード、スプリント、バックログ。
  • 私の 所属するチームのすべてのボード、バックログ、スプリント。
  • すべての すべてのボード、バックログ、スプリントの完全なリスト。

ディレクトリ ページ

[新しいビュー オプション] メニュー

バックログ、ボード、スプリントなどの新しいハブには、新しい [表示オプション] メニューがあります。 これは、レイアウトとページコンテンツをカスタマイズするためのすべてのアクションのための新しいホームです。 [表示オプション] を使用すると、バックログに階層を表示したり、タスクボードの [グループ化] オプションを変更したり、マッピングやスプリントの計画のためにサイド パネルをオンにしたり、作業の詳細グラフを調べるなど、追加のビューを有効にすることができます。

表示オプション

これらのエキサイティングな更新プログラム、新しいチーム プロファイル ウィンドウ、お気に入りの詳細については、 DevOps ブログを参照してください。

カード注釈には、バグとカスタム作業項目の種類が含まれます

カード注釈は、直感的なチェックリスト ビューと操作で愛されています。 以前は、カード注釈は既定のバックログ レベルの型に制限され、バグやカスタム型はサポートされていませんでした。 新しいリリースでは、作業項目の種類に関する制限が削除され、バグとカスタム作業項目の種類をカード注釈として表示する機能が追加されました。

カード注釈のボード設定が拡張され、そのバックログ レベルで使用できるすべての作業項目の種類が含まれます。

注釈の設定

作業項目の注釈が有効になっている場合、その作業項目の種類のカウントは別のチェックリストとしてカードに含まれます。

注釈作業項目

有効な作業項目の種類のクイック作成は、コンテキスト メニューカード使用することもできます。

注釈クイック作成

提案された領域とイテレーションを使用して作業を移動する

同じ領域または反復で作業し、作業項目を移動するときに階層を繰り返し参照するのが一般的な場合があります。 [領域] および [反復] パス コントロールに、[候補] として最近使用した値の一覧が含まれるようになり、簡単に設定して移動できます。

[領域] ドロップダウン リスト

さらに、 イテレーション の日付が名前の右側に含まれるため、作業項目を配信するタイミングをすばやく判断できます。

[イテレーション] ドロップダウン リスト

+/- を使用してイテレーション スケジュール全体のクエリ作業を実行する @CurrentIteration

@CurrentIterationイテレーション スケジュールに基づいてチームが作業を追跡するのに役立つマクロで、整数オフセットがサポートされるようになりました。 - 1 で @CurrentIteration 閉じられなかった作業のタブを簡単に保持するか、+ 1 を使用して将来のイテレーション @CurrentIteration で計画されている作業を先読みします。 詳細については、Microsoft DevOps ブログの @CurrentIteration投稿 を参照してください。

Team パラメーターを使用してクエリイテレーションスケジュールを @CurrentIteration 明確にする

過去にクエリでマクロを @CurrentIteration 使用していた場合、イテレーション スケジュールが異なる Teams 間でチーム コンテキストが変更された場合、結果が異なる可能性があることに気付いたかもしれません。 これで、マクロを使用 @CurrentIteration してクエリを作成または変更するときに、クエリに関連するイテレーション スケジュールを持つチームも選択する必要があります。 Team パラメーターを使用すると、同じクエリで、チーム間でマクロを使用 @CurrentIteration できます。 1 つの例として、異なるイテレーション名とスケジュールを使用する 2 つの異なるチーム プロジェクトの作業項目のクエリがあります。 つまり、スプリントの変化に合わせ、クエリを更新する必要がなくなります。 詳細については、Microsoft DevOps ブログの @CurrentIteration投稿 を参照してください。

Team パラメーター

新しい @TeamAreas マクロを使用してチームのエリア パスで作業を照会する

チームの設定では、1 つ以上のエリア パスを関連付けることができます。これは、 バックログ、 ボード、 プラン、 さらにはダッシュボード をそのチームの作業のみに集中するのに役立ちます。 ただし、チームのクエリを作成する場合は、クエリ句でそのチームの特定のエリア パスを一覧表示する必要がありました。 これで、新しい @TeamAreas マクロを使用して、指定したチームに所有されているエリア パスを簡単に参照できるようになりました。

クエリ エディターのチーム領域マクロ

空のリッチ テキスト フィールドのクエリ

新しい IsEmpty クエリ演算子を使用して、Description などの空のリッチ テキスト フィールドを持つ作業項目を検索します。

リンクとメンションエクスペリエンスで既存の作業項目を簡単に見つける

既存の 2 つの作業項目をリンクする場合は、新しい作業項目検索コントロールを使用して、重要なアイテムを簡単に見つけることができます。 クエリ セレクターは、最近アクセスした作業項目に基づくインライン候補と、ID またはタイトルで特定の作業項目を検索するためのエントリ ポイントに置き換えられました。

作業項目のリンク

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

Repos

ブランチ ピッカーの改善

Azure Reposのほとんどのエクスペリエンスでは、リポジトリとそのリポジトリ内のブランチを選択する必要があります。 多数のブランチを持つ組織でこのエクスペリエンスを向上させるために、新しいブランチ ピッカーをロールアウトしています。 ピッカーを使用すると、お気に入りのブランチを選択したり、ブランチをすばやく検索したりできるようになりました。

ブランチ ピッカー

pull request ポリシーがバイパスされたときに通知を受信する

pull request (PR) ポリシーと ブランチ ポリシーを使用するチームの場合、ユーザーがこれらのポリシーをオーバーライドしてバイパスする必要がある場合があります。たとえば、夜間に運用環境の問題に修正プログラムを展開する場合などです。 開発者が正しいことを行い、オーバーライド機能を慎重に使用することを信頼することは理にかなっています。 同時に、チームは、これらのポリシーオーバーライドが適切な状況で使用されていることを確認する方法が必要です。 これをサポートするために、ポリシーがバイパスされるたびにユーザーとチームが電子メール アラートを受信できるように、新しい通知フィルターが追加されました。 最初に、 プル要求が作成または更新された テンプレートから始め、フィルターの一覧から [ポリシー バイパス ] を選択します。 値として [ ポリシーがバイパスされました ] を選択すると、PR が完了するたびに通知され、ポリシーはバイパスされます。

ポリシー通知をバイパスする

プッシュ保護を終了せずにブランチ ポリシーのバイパスを許可する

ブランチ ポリシーをバイパスする必要が生じるシナリオは多数あります。ビルド中断の原因となった変更の元に戻す、深夜に修正プログラムを適用するなどです。以前は、pull request の完了時にブランチ ポリシーをバイパスする機能を付与されたユーザーをチームが管理できるように、アクセス許可 ("ポリシーの適用から除外" ) を提供していました。 ただし、そのアクセス許可には、PR プロセスを完全にバイパスして、ブランチに直接プッシュする機能も付与されました。

このエクスペリエンスを向上させるために、古いアクセス許可を分割して、バイパスアクセス許可を付与しているチームにより多くの制御を提供しました。 古いものを置き換える新しいアクセス許可は 2 つあります。

  1. [Bypass policies when completing pull requests](pull request 完了時にポリシーをバイパス)。 このアクセス許可を持つユーザーは、pull request に対して "オーバーライド" 操作を使用できます。
  2. [Bypass policies when pushing](プッシュ時にポリシーをバイパス)。 このアクセス許可を持つユーザーは、必要なポリシーが構成されているブランチに直接プッシュできます。

最初のアクセス許可を付与し、2 つ目のアクセス許可を拒否することで、ユーザーは必要に応じてバイパス オプションを使用できますが、ポリシーを使用して誤ってブランチにプッシュしても保護されます。

注意

この変更では、動作変更は発生しません。 以前に "ポリシーの適用から除外する" の 許可 が付与されていたユーザーには、両方の新しいアクセス許可に 対して許可 が付与されるため、PR の完了をオーバーライドし、ポリシーを持つブランチに直接プッシュすることができます。

詳細については、 ブランチのアクセス許可の設定 に関するドキュメントを参照してください。

コミット メッセージを使用して pull request をすばやく記述する

記述的なコミット メッセージを記述すると、Git リポジトリの履歴に価値が追加されます。 品質コミット メッセージを促すために、複数のコミットを持つ新しい pull request (PR) では、共同作成者が手動でタイトルを入力する必要があります。

Pull request の説明は引き続き既定では空ですが、新しい機能を使用すると、PR コミットからのコミット メッセージを PR の説明に簡単に組み込むことができます。 コミット メッセージを追加するには、[ コミット メッセージの追加 ] をクリックして、PR 説明テキストの末尾にコミット メッセージを追加します。

レビュー担当者として既定のチームを使用せずに pull request を作成する

pull request (PR) エクスペリエンスを初めて開始したとき、PR の作成時に選択したチーム コンテキストにすべての PR を割り当てることが理にかなっています。 多くのユーザーがチーム コンテキストと PR 割り当ての間の接続に気付かなかったため、この動作はフラストレーション ポイントでした。

新しいナビゲーションの変更の一環として、チームとのこの既定の関連付けを変更する機会を得ました。 次の 2 つの変更が表示されます。

  1. PR を作成する場合、既定ではレビュー担当者は追加されません。 レビュー担当者リストには、最近 PR に追加された個人とグループを簡単に追加するための機能があります。 必要なレビュー担当者ポリシーは、特定の校閲者がコードをレビューするために確実に追加されるようにするチームにも役立ちます。
  2. Pull Requests ハブには、カスタマイズ可能な新しいセクションがあります。 既定では、このセクションには PR が "自分のチームに割り当てられている" と表示され、古いセクションと同等の機能が提供されます。 ただし、複数のチームに属している場合、このセクションには、いずれかのチームに割り当てられている PR が表示されます。 セクションもカスタマイズ可能です。セクション ヘッダーの近くにある [このビューのカスタマイズ] アクションをクリックするだけです。

テンプレートを使用して pull request の説明を標準化する

適切な pull request の説明を記述することは、レビュー担当者がコードをレビューするときに期待する内容を把握するのに役立つ優れた方法です。 また、テスト、単体テストの追加、ドキュメントの更新など、すべての変更に対して行う必要のある作業を追跡するのに役立つ優れた方法でもあります。 多くのユーザーは、チームが優れた説明を簡単に記述できるように pull request テンプレートを追加するよう要求しており、その機能が追加されました。

既定の PR 説明テンプレートのサポートに加えて、チームは複数のテンプレートを追加できます。このテンプレートは、[PR の作成] ページのメニューに表示されます。 [テンプレートの 追加 ] ボタンをクリックして、リポジトリ内の任意のテンプレートから選択し、PR の説明に追加します。

PR 用テンプレートを追加する

特定のブランチまたはブランチ フォルダーに PR 用の別のテンプレートを適用する場合は、ブランチ固有のテンプレートもサポートされます。 たとえば、"修正プログラム/" で始まるすべてのブランチに固有のテンプレートを作成する場合は、すべての PR に使用されるテンプレートをそれらのブランチに追加できます。

テンプレートを作成して使用する方法の詳細については、 pull request テンプレートのドキュメントを参照してください。

pull request のターゲット ブランチを変更する

ほとんどのチームでは、ほぼすべての pull request が、 や developなどmain、同じブランチを対象とします。 ただし、別のブランチをターゲットにする必要がある場合は、ターゲット ブランチを既定から変更することを忘れてしまいます。 アクティブな pull request のターゲット ブランチを変更する新しい機能により、これは単純なアクションになりました。 pull request ヘッダーのターゲット ブランチ名の近くにある鉛筆アイコンをクリックするだけです。

ターゲット ブランチを変更する

間違いを修正するだけでなく、ターゲット ブランチを変更する機能を使用すると、ターゲット ブランチがマージまたは削除されたときに pull request を簡単に "再ターゲット" できます。 変更が依存する機能を含む機能ブランチを対象とする PR があるシナリオを考えてみましょう。 依存する変更を、機能ブランチ内の他の変更とは分離して確認する必要があるため、最初に をターゲットにしますfeatures/new-feature。 その後、校閲者は自分の変更だけを確認し、適切なコメントを残すことができます。

ここで、機能ブランチも PR がアクティブで、変更前に にmainマージされた場合はどうなりますか? 以前は、変更を破棄して に新しい PR を作成するか、 mainに PR features/new-featureをマージしてから、 から features/new-feature に別の PR を作成する main必要があります。 ターゲット ブランチを更新するこの新しいアクションを使用すると、PR のターゲット ブランチを から features/new-feature に main変更するだけで、すべてのコンテキストとコメントを保持できます。 ターゲット ブランチを変更すると、PR の新しい更新プログラムが作成されます。これにより、ターゲット ブランチが変更される前に、以前の差分を簡単に確認できます。

ターゲット ブランチの更新

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

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

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

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

Pipelines

新しい [ビルド] ページを使用してビルド パイプラインを管理する

いくつかの機能強化を行い、[ ビルド] ページの新しいバージョンをロールアウトしています。 この新しいバージョンでは、すべてのビルド パイプラインのディレクトリと現在のビルドの一覧が組み合わされ、プロジェクトのビルド間をすばやく移動して状態を確認できます。 また、選択したパイプラインのテスト分析のプレビューも含まれています。

[新しいビルド] ページ

改善された書式設定を使用してビルドとデプロイの完了メールをより適切に管理する

ビルドとデプロイの完了メールは、電子メール ルールでフィルター処理できるように更新されました。 これで、件名行に一目で関連性の高い情報が含まれ、本文には詳細が含まれ、そのスタイルは最新のブランドで更新されました。

新しい形式の要素は次のとおりです。

  • [Build result] [pipeline name] - [repository:branch] - [project name] - [commit]
  • [Deployment result] [pipeline name] > [release name] : [stage name]

次に例をいくつか示します。

  • [Build succeeded] IdentityService.CI - MyRepo:main - MyProject - d3b90b80
  • [Deployment succeeded] New release pipeline > NotificationSpecialRelease-1 : Stage 1

新しい統合 Azure Pipelines の用語に従う

ビルドとリリースを通じて、同様の概念に対してさまざまな用語が歴史的に使用されてきました。 それ以外の場合、用語の意味はあいまいでした。 たとえば、 エージェント プールとエージェント キューの違いを示 します。

用語は、その概念を明確にするために Azure Pipelines で統一されています。 次の統合用語が表示されます。

従来の用語 統合用語 意味
ホストされたエージェント Microsoft によってホストされるエージェント Microsoft によって管理されるクラウドでホストされるインフラストラクチャ上で実行されるビルド/リリース エージェント。
プライベート エージェント 自己ホスト エージェント ユーザーが提供および管理するマシン上で実行されるビルド/リリース エージェント。
エージェント プール エージェント プール ビルドまたはリリースを実行できるエージェント マシンのorganizationレベルのセット。
エージェント キュー エージェント プール ビルドまたはリリースを実行できるエージェント マシンのプロジェクト レベルのセット。 organization レベルのエージェント プールにリンクされます。
ビルド定義 ビルド パイプライン アプリケーションのビルド ステップのエンド ツー エンドセット。
Build Build 実行中または実行済みのビルド パイプラインのインスタンス。
フェーズ ジョブ エージェントで順次または並列に実行される一連のタスク。 ビルドまたはリリース パイプラインには、1 つのジョブまたは複数のジョブのグラフを含めることができます。
リリース定義 リリース パイプライン アプリケーションをさまざまな段階にまたがってデプロイするための、エンド ツー エンドのリリース手順のセット。
リリース リリース 実行中または実行済みのリリース パイプラインのインスタンス。
環境 段階 リリース パイプラインから生成されたリリースをデプロイする場所を表す、論理的で独立したエンティティ。
同時実行ジョブ/パイプライン 並列ジョブ 並列ジョブを使用すると、organizationで一度に 1 つのビルド ジョブまたはリリース ジョブを実行できます。 使用可能な並列ジョブが増えるので、より多くのビルド ジョブとリリース ジョブを同時に実行できます。
サービス エンドポイント サービス接続 外部サービスに接続してビルドまたはリリースでタスクを実行するために使用される設定のグループ (資格情報など)。

詳細については、 概念に関する ドキュメントを参照してください。

新しいリリース ページを使用してリリース パイプラインを管理する

リリース ランディング ページでは、完全に再設計された新しいユーザー エクスペリエンスを利用できます。 左側で頻繁にリリースするリリース パイプラインの一覧を参照してください。 パイプラインを検索して、お気に入りに追加することもできます。

リリース ランディング ページ

フォルダー ビューに変更して、organizationとセキュリティ用のフォルダーを作成します。 セキュリティはフォルダー レベルで設定できます。

フォルダーを解放する

リリースの進行状況を視覚化する

新しいリリースの進行状況ビューには、デプロイの進行状況のライブ更新と、詳細へのワンクリック アクセスが表示されます。 新しいビューでは、リリース パイプラインが視覚化されるため、何が起こっているかを理解しやすくなり、リリースのさまざまな段階で適切な詳細とアクションを表示できます。

リリース パイプライン ビュー

パイプライン、リリースの詳細、環境

[パイプライン] ビューには、リリースの成果物と、それらがデプロイされる環境が表示されます。 [リリース] 領域には、リリース トリガー、成果物のバージョン、タグなどのリリースの詳細が表示されます。

環境は、その状態と詳細な進行状況を理解するのに役立つ方法でモデル化されます。 環境内の状態リンクをクリックすると、いつでもログにアクセスできます。

環境

デプロイ前とデプロイ後

環境に対してデプロイ前またはデプロイ後の条件が設定されている場合は、承認とゲートが存在する環境に示されます。 承認とゲートの進行状況は、環境の状態にも表示されます。 環境の右側または左側にある環境の条件アイコンをクリックして、アクションを実行したり、詳細を表示したりできます。

環境のリリース アクション

コミットと作業項目

環境をクリックすると、新しいリリースごとに、関連付けられているコミットと作業項目の一覧を環境ごとに個別に確認できます。 一覧が長い場合は、フィルターを使用して、関心のあるコミットまたは作業項目を見つけます。

コミットと作業項目を解放する

デプロイの進行状況とログ

環境には、完了したフェーズとタスクの数や実行時間など、進行中のデプロイのライブ更新が表示されます。 環境の状態をクリックすると、ログを含むビューが開き、現在アクティブになっている内容がフォーカスされます。

ログをクリックして、フォーカスされたビューを入力できます。

リリース ログの詳細

タスクに対する Azure DevOps Server 2019 へのアップグレードの影響: ターゲット コンピューター上の Windows マシン のファイル コピーと PoweShell

TFS 2017 RTM では、テスト ハブの下のマシン グループは 非推奨 となりました。 Azure DevOps Server 2019 では、マシン グループ サービスは使用できなくなります。 これは、'Windows Machine File Copy' タスク バージョン 1.* および 'PowerShell on Target Machines' タスク バージョン 1.* のユーザーに影響します。 パイプラインが引き続き動作するには、

  • "Windows マシン ファイル コピー" タスク バージョン 2.* に切り替え、マシン名だけでなく、ターゲット コンピューターの完全な fqdn を指定する必要があります。
  • また、'Powershell on Target Machine' タスク バージョン 2.* 以降に切り替え、コンピューター名またはマシン名の完全な fqdn の後に Windows リモート管理ポート (http/https) を指定します。 たとえば、targetMachine:5985 や targetMachine:5986 などです。

テスト結果と拡張性

テスト実行の結果も環境ごとに表示されます。 テスト結果をクリックすると、プロセスに寄与する他の拡張機能からの結果を含むテストの詳細を含むビューが開きます。

リリース テスト結果

既存の拡張機能は、この新しいビューで機能します。さらに、拡張機能を開発して環境に関するさらに多くの情報を表示できるようにするための新しい機能拡張ポイントもあります。 詳細については、コントリビューションと拡張機能のドキュメントを参照してください。

YAML を使用してビルドを構成する

Azure DevOps Serverでは、YAML ベースのビルド パイプラインを使用できます。 リポジトリにチェックインされた YAML ファイルを使用して、継続的インテグレーション パイプラインを自動化します。 YAML スキーマの完全なリファレンスについては、 こちらを参照してください。

YAML ベースのビルド パイプラインをよりシームレスにサポートするために、作成するすべての新しいリソース (サービス接続、変数グループ、エージェント プール、セキュリティで保護されたファイルなど) の既定の動作を、そのプロジェクトのすべてのパイプラインで使用できるように変更しました。 リソースをより厳密に制御する場合は、既定の承認モデルを無効にすることができます (下の図を参照)。 その場合、リソースを使用するアクセス許可を持つユーザーは、リソース参照が YAML ファイルに追加された後、Web エディターにパイプラインを明示的に保存する必要があります。

YAML

大規模な製品には、相互に依存する複数のコンポーネントがあります。 多くの場合、これらのコンポーネントは個別に構築されます。 アップストリーム コンポーネント (ライブラリなど) が変更された場合、ダウンストリームの依存関係を再構築して再検証する必要があります。 Teams は通常、これらの依存関係を手動で管理します。

これで、別のビルドが正常に完了したときにビルドをトリガーできます。 アップストリーム ビルドによって生成された成果物は、後のビルドでダウンロードして使用できます。また、Build.TriggeredBy.BuildId、Build.TriggeredBy.DefinitionId、Build.TriggeredBy.BuildDefinitionName の各変数からデータを取得することもできます。 詳細については、 ビルド トリガーに関する ドキュメントを参照してください。

ビルド チェーンのセットアップ

場合によっては、単一 のマルチフェーズ ビルド がニーズを満たす可能性があることに注意してください。 ただし、ビルド完了トリガーは、要件に異なる構成設定、オプション、または依存プロセスを所有する別のチームが含まれている場合に便利です。

エージェントをローカルで更新する

ギャラリーからインストールするタスクでは、新しいバージョンのパイプライン エージェントが必要になる場合があります。 Azure DevOps Serverがインターネットに接続できる場合は、新しいバージョンが自動的にダウンロードされます。 そうでない場合は、各エージェントを手動でアップグレードする必要があります。 このリリース以降では、インターネットからではなく、ローカル ディスク上のエージェント パッケージ ファイルを検索するようにAzure DevOps Serverを構成できます。 これにより、Azure DevOps Serverをインターネットに公開することなく、使用できるエージェントのバージョンを柔軟に制御できます。

新しいビルドステータスバッジの URL

リポジトリのホームページに埋め込まれたビルド バッジは、リポジトリの正常性を示す一般的な方法です。 これまではビルド バッジがありましたが、いくつかの問題がありました。

  • URL が直感的ではなかった
  • バッジはブランチに固有のものではありませんでした
  • ユーザーがバッジをクリックして、その定義の最新のビルドにユーザーを連れて行く方法はありませんでした

現在、これらの問題を解決するビルド バッジ用の新しい API をロールアウトしています。 新しい API を使用すると、ユーザーはブランチごとの状態を発行でき、選択したブランチの最新ビルドにユーザーを連れて行くことができます。 新しい [ビルド] ページで [状態バッジ] メニュー アクションを選択すると、新しいステータス バッジ URL の Markdown を取得できます。

下位互換性のために、古いビルド バッジの URL も引き続き尊重します。

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

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

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

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

パイプラインでのコンプライアンスとセキュリティの検証をAzure Policyする

開発、セキュリティ、運用を一緒にしながら、開発プロセスの早い段階でソフトウェアの安定性とセキュリティを確保したいと考えています。 これを行うために、Azure Policyのサポートが追加されました。

Azure Policy では、リソースに対してルールと効果を適用するポリシー定義によって IT の問題を管理および防止できます。 Azure Policyを使用する場合、リソースは企業の標準とサービス レベルアグリーメントに準拠し続けます。

リリース プロセスの一環として、コンプライアンスとセキュリティのガイドラインに準拠するために、Azure リソース グループのデプロイ エクスペリエンスが強化されました。 ここでは、ARM テンプレートのデプロイ中に違反が発生した場合に、関連するポリシー関連のエラーで Azure リソース グループのデプロイ タスクを失敗させます。

Azure Policy

さらに、リリース定義テンプレートAzure Policy追加しました。 これにより、ユーザーは Azure ポリシーを作成し、リリース定義自体からリソース、サブスクリプション、または管理グループにこれらのポリシーを割り当てることができます。

Azure Policy テンプレート

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

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

パイプラインでのテストのエクスペリエンスの向上

[テスト] タブ に、パイプラインの豊富なコンテキスト内テスト情報を提供する最新のエクスペリエンス が追加されました。 新しいエクスペリエンスでは、進行中のテスト ビュー、完全なページ デバッグ エクスペリエンス、コンテキスト テスト履歴、中止されたテスト実行のレポート、実行レベルの概要が提供されます。

新しいテスト ハブ

進行中のテストの実行を表示する

統合テストや機能テストなどのテストは長時間実行できるため、特定の時点でテストの実行を確認することが重要です。 In-Progress テスト ビューでは、テストの実行が完了するまで待機してテスト結果を把握する必要がなくなりました。 結果は、実行時にほぼリアルタイムで利用でき、迅速にアクションを実行するのに役立ちます。 エラーのデバッグや中止、バグの提出、パイプラインの中止を行うことができます。 この機能は、現在、マルチ エージェント フェーズで VS テスト タスク を使用するか、 テスト結果の発行 タスクを使用するか、API を使用してテスト結果を発行して、ビルド パイプラインとリリース パイプラインの両方で使用できます。 今後は、単一エージェントを使用したテスト実行のために、このエクスペリエンスを拡張する予定です。

次のビューは、新しいリリースの進行状況ビューの In-Progress テストの概要を示しています。特定の時点でのテストの合計数とテスト失敗の数を報告しています。

進行中のテスト ビュー

上記の In-Progress テストの概要をクリックすると、テストの詳細な概要と、失敗または中止されたテスト情報をTest Plansで表示できます。 テストの概要は定期的に更新され、新しい結果の可用性に基づいて、必要に応じて詳細ビューを更新できます。

詳細なテストの概要

テスト実行のデバッグの詳細を完全なページで表示する

エラー メッセージとスタック トレースは本質的に長く、デバッグ中に詳細を表示するのに十分な不動産が必要です。 イマーシブ デバッグ エクスペリエンスを実現するために、テストまたはテストの実行ビューをフル ページ ビューに拡張しながら、バグの作成や現在のテスト結果の要件の関連付けなどのコンテキスト操作で必要な操作を実行できるようになりました。

ページ全体のデバッグ

テスト履歴をコンテキスト内で表示する

これまで、チームはテスト結果の履歴を表示するために [実行 ] ハブに移動する必要があります。 新しいエクスペリエンスにより、ビルドとリリース用の [Test Plans] タブ内のコンテキストでテスト履歴が適切に表示されます。 テスト履歴情報は、選択したテストの現在のビルド定義または環境から順に段階的に提供され、その後にビルドとリリース用の他のブランチと環境が続きます。

コンテキスト内テスト履歴

中止されたテストを表示する

テストコードが正しくない、テスト中のソース、環境の問題など、複数の理由でテストの実行が中止される可能性があります。 中止の理由に関係なく、動作を診断し、根本原因を特定することが重要です。 中止されたテストとテストの実行を、Test Plansの完了した実行と共に表示できるようになりました。 この機能は現在、マルチ エージェント フェーズで VS テスト タスク を使用するか、API を使用してテスト結果を発行する、ビルド パイプラインとリリース パイプラインの両方で使用できます。 今後は、単一エージェントを使用したテスト実行のために、このエクスペリエンスを拡張する予定です。

中止されたテストを表示する

テスト履歴でのテストの追跡可能性とリリース環境のサポート

テストが実行されているさまざまなリリース環境によってグループ化された自動テストの履歴を表示するためのサポートが追加されています。 リリース環境をリリース パイプラインまたはテスト環境としてモデル化し、このような環境間でテストを実行している場合は、テストが開発環境で合格しているが、統合環境で失敗しているかどうかを確認できます。 英語ロケールを渡しているが、トルコ語のロケールを持つ環境では失敗しているかどうかを確認できます。 環境ごとに、最新のテスト結果の状態が表示され、その環境でテストが失敗した場合は、テストが失敗したリリースも見つかります。

要約されたテスト結果を確認する

テストの実行中に、テストによって、全体的な結果に寄与するテストの複数のインスタンスが生成される場合があります。 たとえば、エラーが原因で再実行されるテスト、他のテストの順序付き組み合わせで構成されるテスト (順序付きテストなど)、指定された入力パラメーターに基づいて異なるインスタンスを持つテスト (データドリブン テスト) などがあります。 これらのテストは関連しているため、個々のテスト結果に基づいて派生した全体的な結果と共に報告する必要があります。 この更新プログラムでは、リリース の [テスト ] タブに階層として表示されるテスト結果の改善されたバージョンが導入されました。 例を見てみましょう。

以前は、 VS テスト タスクで失敗したテストを再実行する機能が導入されました。 ただし、テストの最後の試行についてのみ報告しました。この機能の有用性はやや制限されています。 テスト実行の各インスタンスを試行として報告するように、この機能を拡張しました。 さらに、Test Management API では、階層的なテスト結果を発行してクエリを実行する機能がサポートされるようになりました。 詳細については、 テスト結果 API のドキュメントを参照してください。

概要デバッグのテスト

注意

テストの概要セクションのメトリック (テストの合計数、合格など) は、テストの個々の反復ではなく、階層のルート レベルを使用して計算されます。

パイプラインでテスト分析を表示する

テスト品質を経時的に追跡し、テスト資料を改善することは、正常なパイプラインを維持するための鍵です。 テスト分析機能を使用すると、ビルドとリリース パイプラインのテスト データをほぼリアルタイムで可視化できます。 繰り返し発生する影響の大きい品質上の問題を特定することで、パイプラインの効率を向上させることができます。

さまざまな要素でテスト結果をグループ化したり、ブランチまたはテスト ファイルの主要なテストを特定したり、特定のテストにドリルダウンして傾向を表示したり、フラキネスなどの品質の問題を理解したりできます。

ビルドとリリースのテスト分析を表示し、以下のプレビューを表示します。

テスト分析

詳細については、こちら を参照してください。

複数のエージェントレス タスクを使用して定義を簡略化する

エージェントレス フェーズのタスクは、 によって調整され、サーバー上で実行されます。 エージェントレス フェーズでは、エージェントやターゲット コンピューターは必要ありません。 エージェント フェーズとは異なり、定義内の各エージェントレス フェーズに追加できるタスクは 1 つだけです。 これは、プロセス内に複数のエージェントレス タスクがある場合に複数のフェーズを追加する必要があり、定義がかさばることを意味しました。 この制限を緩和しました。これにより、エージェントレス フェーズで複数のタスクを維持できます。 同じフェーズのタスクは、エージェント フェーズの場合と同様に、順番に実行されます。 詳細については、 サーバー フェーズ のドキュメントを参照してください。

リリース ゲートを使用して段階的にデプロイとフェーズデプロイを公開する

リリース ゲートを使用して、リリースを次の環境に昇格させる前に満たす必要があるアプリケーションの正常性基準を指定できます。 指定されたすべてのゲートは、デプロイの前またはデプロイ後に、すべてが成功するまで定期的に評価されます。 4 種類のゲートをすぐに使用でき、 Marketplace からゲートを追加できます。 デプロイに必要なすべての条件が満たされたことを監査できます。 詳細については、リリース ゲートに関する文書を参照してください。

リリース ゲート パネル

ゲートが一貫して成功するまでデプロイを保持する

リリース ゲートを使用すると、リリースが次の環境に昇格される前に正常性基準を自動的に評価できます。 既定では、すべてのゲートに対して 1 つのサンプルが成功した後にリリースが進行します。 ゲートが不規則で、正常に受信されたサンプルがノイズである場合でも、リリースは進行します。 これらの種類の問題を回避するために、進行状況の前に正常性の整合性を最小限の期間検証するようにリリースを構成できるようになりました。 実行時に、リリースでは、昇格を許可する前に、ゲートの連続した評価が成功することが保証されます。 評価の合計時間は"再評価までの時間" によって異なり、通常は構成された最小期間を超えます。 詳細については、 ゲートを使用したリリースデプロイ制御 に関するドキュメントを参照してください。

ゲートの保留設定

配置グループ内の新しいターゲットに自動的にデプロイする

以前は、新しいターゲットがデプロイ グループに追加されたとき、すべてのターゲットが同じリリースになるように手動デプロイが必要でした。 これで、最後に成功したリリースを新しいターゲットに自動的にデプロイするように環境を構成できるようになりました。 詳細については、 デプロイ グループ のドキュメントを参照してください。

デプロイ グループ

ビルド後処理によってタグ付けされたビルドを継続的にデプロイする

継続的デプロイ トリガーは、ビルドの完了時にリリースを作成します。 ただし、ビルドが後処理されることがあり、その処理が完了した後にのみビルドを解放する必要があります。 これで、リリースのトリガー フィルターで、後処理中に割り当てられるビルド タグを活用できるようになりました。

ビルド タグ トリガー

リリース時に変数を設定する

リリース定義で、リリースの作成時に設定する変数を選択できるようになりました。

リリース変数

リリースの作成時に変数に指定された値は、そのリリースでのみ使用されます。 この機能は、下書き作成の複数の手順を回避し、下書きの変数を更新し、変数を使用してリリースをトリガーするのに役立ちます。

リリースのリリース変数

環境変数をタスクに渡す

CI/CD タスク作成者は、task.json で新しいプロパティ showEnvironmentVariables を設定して、環境変数をタスクに渡すことができます。 これを行うと、ビルド エディターのタスクに追加のコントロールがレンダリングされます。 これは、 Powershell、 Cmd、 Bash の各タスクで使用できます。

環境変数を渡す

これにより、次の 2 つのシナリオが可能になります。

  • タスクには、変数名に大文字と小文字が保持された環境変数が必要です。 たとえば、上記の例では、タスクに渡される環境変数は "FOO" ではなく "foo" になります。
  • これにより、シークレット値をスクリプトに安全な方法で渡すことができます。 エージェント上のオペレーティング システムは、引数を含むプロセスの呼び出しをログに記録できるため、シークレットを引数としてスクリプトに渡すことをお勧めします。

変数グループを複製する

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

変数グループを複製する

Note

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

デプロイのリリース ゲートを無視する

リリース ゲートを使用すると、リリースが次の環境に昇格される前に正常性基準を自動的に評価できます。 既定では、リリース パイプラインは、すべてのゲートが同時に正常な場合にのみ進行します。 リリースの迅速化や正常性の手動チェックの後など、特定の状況では、承認者はゲートを無視し、そのゲートがまだ正常と評価されていない場合でもリリースの進行を許可することができます。 詳細については 、リリース ゲート のドキュメントを参照してください。

ゲートを無視する

pull request リリース トリガーを使用して追加のテストを実行する

pull request (PR) に基づいてビルドをトリガーし、しばらくの間、マージの前にその迅速なフィードバックを得ることができました。 これで、リリースの PR トリガーも構成できます。 リリースの状態はコード リポジトリにポストバックされ、PR ページに直接表示されます。 これは、PR ワークフローの一部として追加の機能テストまたは手動テストを実行する場合に役立ちます。

リリースの PR トリガー

証明書で認証するサービス プリンシパルを使用して Azure サービス接続を作成する

認証用のサービス プリンシパルと証明書を使用して Azure サービス接続を定義できるようになりました。 証明書で認証するサービス プリンシパルをサポートする Azure サービス接続を使用して、AD FS で構成された Azure Stack にデプロイできるようになりました。 証明書認証を使用してサービス プリンシパルを作成するには、証明書で 認証するサービス プリンシパルを作成する方法に関する記事を参照してください。

サービス プリンシパルを使用して接続する

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 関数にデプロイできます。

Xcode タスクでは、新しくリリースされた Xcode 10 がサポートされます

Apple の Xcode 10 リリースと合わせて、プロジェクトをビルドするように設定したり、Xcode 10 で特別にテストしたりできます。 パイプラインでは、Xcode バージョンの マトリックス と並行してジョブを実行することもできます。 Microsoft でホストされている macOS エージェント プールを使用して、これらのビルドを実行できます。 Azure Pipelines で Xcode を使用するための ガイダンス を参照してください。

Xcode 10

Helm を使用して Kubernetes へのデプロイを効率化する

Helm は、Kubernetes アプリケーションのインストールと管理を効率化するツールです。 また、昨年は多くの人気とコミュニティのサポートを得ています。 リリースの Helm タスクは、Helm チャートをパッケージ化して Azure Container Service (AKS) またはその他の Kubernetes クラスターにデプロイできるようになりました。

この Helm タスクが追加され、Kubernetes クラスターにコンテナーを配信するための Helm ベースの CI/CD パイプラインを設定できるようになりました。 詳細については、 Kubernetes を使用した Azure Container Service へのデプロイ に関するドキュメントを参照してください。

helm タスク

リリースで使用される Helm バージョンを制御する

Helm ツール インストーラー タスクは、インターネットまたはツール キャッシュから特定のバージョンの Helm を取得し、エージェントの PATH (ホステッドまたはプライベート) に追加します。 このタスクを使用して、 .NET Core cli タスクなどの後続のタスクで使用される Helm のバージョンを変更します。 ビルドまたはリリース定義で Helm Deploy タスクの前にこのタスクを追加すると、適切な Helm バージョンでアプリをパッケージ化してデプロイできるようになります。 このタスクは、必要に応じて kubectl ツールをインストールするのにも役立ちます。これは、Helm が動作するための前提条件です。

Azure Database for MySQLに継続的にデプロイする

Azure Database for MySQL - Azure の MySQL データベースにサービスとして継続的にデプロイできるようになりました。 バージョン管理で MySQL スクリプト ファイルを管理し、PowerShell スクリプトではなくネイティブ タスクを使用してリリース パイプラインの一部として継続的にデプロイします。

強化された Windows リモート PowerShell ベースのタスクを使用する

Windows リモート PowerShell ベースの新しいタスクと改善されたタスクを利用できます。 これらの機能強化には、いくつかのパフォーマンス修正が含まれており、ライブ ログとコンソール出力コマンド (Write-Host や Write-Output など) がサポートされています。

PowerShell on Target タスク (バージョン: 3.*): インライン スクリプトの追加、PSSession オプションの変更、"ErrorActionPreference" の制御、標準エラー時の失敗を行うことができます。

Azure ファイル コピー タスク (バージョン: 2.*): GitHub の問題に対処する最新の AzCopy (v7.1.0) に付属しています。

GitHub Enterprise または外部 Git 成果物のブランチをフィルター処理する

GitHub Enterprise または外部 Git リポジトリからリリースする場合は、リリースされる特定のブランチを構成できるようになりました。 たとえば、特定のブランチから運用環境へのビルドのみをデプロイできます。

ブランチ フィルター

Go で記述されたアプリケーションをビルドする

Go Tool インストーラー タスクを使用して、1 つ以上のバージョンの Go Tool をすぐにインストールします。 このタスクは、プロジェクトに必要な特定のバージョンの Go Tool を取得し、ビルド エージェントの PATH に追加します。 対象の Go Tool のバージョンがエージェントに既にインストールされている場合、このタスクはダウンロードして再インストールするプロセスをスキップします。

Go タスクは、依存関係のダウンロード、ビルド、またはアプリケーションのテストに役立ちます。 このタスクを使用して、任意のカスタム Go コマンドを実行することもできます。

パイプラインでインラインまたはファイルベースの Python スクリプトを実行する

新しい Python スクリプト タスクを使用すると、パイプラインでの Python スクリプトの実行が簡略化されます。 タスクはリポジトリ内の Python ファイル (.py) からスクリプトを実行するか、タスクの設定にスクリプトを手動で入力してパイプラインの一部として保存できます。 このタスクでは、パスで Python のバージョンが使用されます。または、使用する Python インタープリターへの絶対パスを指定できます。

改善された Xcode ビルドを活用し、xcpretty からの出力をテストする

xcpretty は xcodebuild 出力の読みやすさを高め、JUnit 形式でテスト結果を生成します。 Xcode ビルド タスクは、ホストされている macOS エージェント上にあるように、エージェント コンピューターで使用できる場合に xcpretty を自動的に使用するようになりました。 xcpretty の出力は xcodebuild の出力とは異なり、詳細が少ない場合がありますが、ビルドごとに完全な xcodebuild ログを使用できるようにします。

Test Plans

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

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

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

Azure Test Runner

Azure Test Runner のインストール

Artifacts

アップストリーム ソース

Azure DevOps Server 2019 では、Azure Artifacts フィードで利用できるアップストリーム ソースが大幅に更新されます。

  • 以前の TFS リリース nuget.org 作成された既存のフィードにアップストリーム ソースを追加できます。 アップグレードする前に注意する必要がある動作の変更など、詳細については、フィードのパッケージの上にあるバナーを探してください。
  • 他のAzure DevOps Server フィードをアップストリーム ソースとしてフィードに追加できます。つまり、フィードを介してそれらのフィードから NuGet パッケージと npm パッケージを使用できます。

また、Azure Artifacts に新しいロール "コラボレーター" も導入しました。 コラボレーターは、アップストリーム ソースからパッケージを保存できますが、パッケージ パッケージをフィードに直接発行することはできません (たとえば、nuget publish を使用)。 これにより、エンジニアがアップストリーム ソースから新しいパッケージを使用できるようにしながら、信頼できるユーザーまたはビルド システムにパッケージの発行を制限できます。

パッケージをフォローする

すべてのパッケージに対して新しい [フォロー ] ボタンを使用して通知を簡単に設定できるようになりました。 [ フォロー ] ボタンは、リリース ビューとも互換性があります。 ビューを使用してパッケージを見ている間にパッケージをフォローすると、そのビューに昇格された新しいバージョンの更新プログラムのみが取得されます。

手動で保存しなくてもフィード設定を変更する

フィード設定ページの操作の一部が改善されました。 これで、アップストリームやアクセス許可の追加など、行った変更がすぐに保存されます。 つまり、設定ピボットを切り替えるときに変更を失う心配はありません。

新しいクロスプラットフォームの Credential Provider for NuGet を使用して認証を簡単にする

認証された NuGet フィードとの対話が大幅に向上しました。 新しい .NET Core ベース の Azure Artifacts 資格情報プロバイダー は、Windows、macOS、Linux 上の msbuild、dotnet、nuget(.exe) と連携します。 Azure Artifacts フィードのパッケージを使用する場合、資格情報プロバイダーは、使用している NuGet クライアントに代わってトークンを自動的に取得して格納します。 構成ファイルにトークンを手動で格納および管理する必要がなくなりました。

新しいプロバイダーを取得するには、 GitHub に移動し、クライアントとプラットフォームの指示に従います。

ファイル共有に公開するときにシンボルを圧縮する

ファイル共有に発行されるシンボルの圧縮をサポートするために、 インデックス & シンボルの発行タスクを更新しました。

シンボルの圧縮

Wiki

Git リポジトリから Wiki としてマークダウン ファイルを発行する

開発者は、コード リポジトリで "API"、"SDK"、および "コードを説明するヘルプ ドキュメント" のドキュメントを作成します。 読者は、適切なドキュメントを見つけるためにコードを調べる必要があります。 これで、コード リポジトリからマークダウン ファイルを発行し、Wiki でホストできます。

Wiki アクションとしてのパブリック コード

Wiki 内から、まず [コードを Wiki として発行] をクリックします。 次に、昇格する必要がある Git リポジトリ内のフォルダーを指定できます。

[ページの発行] ダイアログ

[発行] をクリックすると、選択したフォルダーの下にあるすべてのマークダウン ファイルが Wiki として発行されます。 これにより、ブランチの先頭が Wiki にマップされ、Git リポジトリに対して行った変更が直ちに反映されます。

詳細については、 製品ドキュメントのブログ投稿 を参照してください。

ページ内の見出しへのリンク

Wiki ページのセクション見出しの横にあるリンク アイコンをクリックすると、そのセクションに直接 URL を生成できます。 その後、その URL をコピーしてチーム メンバーと共有し、そのセクションに直接リンクできます。

Wiki の見出し URL

フォルダーにファイルとイメージを添付する

Wiki ページをオフラインで編集する場合は、Wiki ページと同じディレクトリに添付ファイルや画像を追加する方が簡単です。 これで、Wiki の任意のフォルダーに添付ファイルまたは画像を追加し、ページにリンクできます。

Git リポジトリ フォルダー内の Wiki イメージ

Wiki にビデオを埋め込む

Microsoft Streamや YouTube などのオンライン サービスから Wiki ページにビデオを埋め込むことができます。 埋め込みビデオ URL は、次の構文を使用して追加できます。

::: video
<iframe width="560" height="315" src="https://www.youtube.com/embed/7DbslbKsQSk" frameborder="0" allow="autoplay; encrypted-media" allowfullscreen></iframe>
:::

Wiki にビデオを埋め込む

Wiki の名前を変更する

Wiki ユーザー インターフェイスで、および REST API を使用して Wiki の名前を変更できるようになりました。 [ その他 ] メニューの [ Wiki の名前を変更 ] をクリックして、Wiki に覚えやすい名前を付けます。

Wiki の名前を変更する

新しいタブでページを開く

Wiki ページを右クリックして新しいタブで開くか、Ctrl キーを押しながら Wiki ページを左クリックして新しいタブで開くことができます。

Wiki の新しいタブ

Wiki ページのタイトルに特殊文字を保持する

などの : < > * ? | -特殊文字を含む Wiki ページを作成できるようになりました。 "FAQ" のようなタイトルを含むページが表示されるようになりました。 または「セットアップガイド」は Wiki で作成できます。 次の文字は、UTF-8 でエンコードされた文字列に変換されます。

文字 エンコードされた文字列
: %3A
< %3C
> %3E
* %2A
? %3F
| %7C
- %2D

正しくリンクされていない Wiki 内のすべてのリンクは、明確な赤い色と壊れたリンク アイコンで表示され、Wiki ページ内のすべての壊れたリンクの視覚的な手がかりを得ます。

Wiki の壊れたリンク

壊れたページ リンクは、ドキュメント ソリューションのページ品質が低下する主な原因の 1 つです。 以前 の Wiki では、ツリー構造内でページを移動したり、ページの名前を変更したりすると、他のページや作業項目からのページへのリンクが解除される可能性があります。 リンクが壊れる前に、リンクをチェックして修正できるようになりました。

重要

ページ内のリンクに []() マークダウン構文を使用し、作業項目の Wiki ページ リンクの種類を使用して、 Wiki がこれらの破損している可能性のあるリンクを見つけて修正できるようにします。 この機能では、作業項目のプレーンテキスト URL とハイパーリンクは取得されません。

ページの名前を変更または移動すると、影響を受ける絶対リンクまたは相対リンクをチェックするように求められます。

[ページの移動] ダイアログ

その後、アクションを実行する前に、影響を受ける ページ リンク と 作業項目 の一覧が表示されます。

ページ リンクの移動

Wiki ページの目次を作成する

Wiki ページが長くなる場合があり、コンテンツは複数の見出しにまとめられます。 これで、 構文を使用して、少なくとも 1 つの見出しを持つ任意のページに目次を [[_TOC_]] 追加できるようになりました。

Wiki の目次

また、ページの編集時に書式設定ウィンドウの適切なボタンをクリックして目次を挿入することもできます。

Wiki TOC を挿入する

Azure DevOps での markdown の使用の詳細については、マークダウン ガイダンスのドキュメントを参照してください。

YAML タグを使用した Wiki ページとコード プレビューのサーフェス メタデータ

ドキュメントにメタデータを追加すると、読者や検索インデックスが意味のあるコンテンツを取得して表示するのに役立ちます。 この更新では、ファイルの先頭に YAML ブロックを含むファイルは、1 つのヘッドと 1 行のメタデータ テーブルに変換されます。 YAML ブロックは、3 つの破線の間に有効な YAML セットの形式を取る必要があります。 すべての基本的なデータ型、リスト、オブジェクトを値としてサポートしています。 構文は、 Wiki とコード ファイルのプレビューでサポートされています。

YAML タグの例:

---
tag: post
title: Hello world
---

YAML テーブル

リストを含む YAML タグの例:

---
tags:
- post
- code
- web
title: Hello world
---

リストを含む YAML テーブル

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

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

レポート

レポート用の Analytics Marketplace 拡張機能を使用できるようになりました

Azure DevOps Serverで Analytics Marketplace 拡張機能を使用できるようになりました。 分析は、Azure DevOps とAzure DevOps Serverのレポートの未来です。 Analytics 拡張機能をインストールすると、 高度なウィジェット、 Power BI 統合、 OData アクセスが提供されます。

詳細については、「分析とは」と「レポート ロードマップ」をチェック。 分析はパブリック プレビュー段階です。 現在、パイプラインを介したボードと自動テストの結果のデータが含まれています。 「Analytics Service で使用できるデータ」を参照してください。

新しいビルド ダッシュボード ウィジェットを使用してビルド履歴を調査する

ダッシュボードに追加できる、新しく改善されたビルド履歴ウィジェットがあります。 このウィジェットを使用すると、ダッシュボード上の特定のブランチからのビルドの履歴を表示し、匿名の訪問者用のパブリック プロジェクトで構成できるようになりました。

重要

XAML ビルドに関する分析情報を探している場合は、引き続き古いウィジェットを使用し、 XAML ビルドから新しいビルドへの移行に関する記事を参照してください。 それ以外の場合は、新しいウィジェットに移動することをお勧めします。

フィードバック

皆様のご意見をお待ちしております。 問題を報告したり、アイデアを提供したり、Developer Communityで追跡したり、Stack Overflow に関するアドバイスを得ることができます。

ページの先頭へ