Azure DevOps Server 2019 リリースノート


| 開発者コミュニティ
| システム要件と互換性
| ライセンス条項
| DevOps ブログ
| Sha-1 ハッシュ |


この記事では、Azure DevOps Server 2019 の最新リリースに関する情報を紹介します。 Azure DevOps Server 製品をダウンロードするには、 Azure DevOps Server のダウンロードページにアクセスしてください。

Azure DevOps Server 2019 の詳細については、「 Azure DevOps Server の要件」を参照してください。 Team Foundation Server 製品をダウンロードするには、 visualstudio.com/downloads のページを参照してください。

Azure DevOps Server への直接アップグレードは Team Foundation Server 2012 以降でサポートされています。 Tfs が TFS 2010 以前に配置されている場合は、Azure DevOps Server 2019 にアップグレードする前に、いくつかの中間手順を実行する必要があります。 詳細については、 インストールページ を参照してください。


Azure DevOps Server 2019.0.1 Patch 10 リリース日: 2021 年4月13日

以下を修正する Azure DevOps Server 2019.0.1 の修正プログラムをリリースしました。

修正プログラム10を適用するには、タスクをインストールする必要があり AzureResourceGroupDeploymentV2 ます。

AzureResourceGroupDeploymentV2 タスクのインストール

注意

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

インストール

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

  2. お使いのコンピューターに従って、Node.js 14.15.1 と npm (Node.js ダウンロードに含まれています) をダウンロードしてインストールします。

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

npm install -g tfx-cli
  1. フルアクセス 特権で個人用アクセストークンを作成し、コピーします。 この個人用アクセストークンは、 tfx-cli ログイン コマンドを実行するときに使用されます。

  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 CheckInstall 。 devops2019.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 タスクのインストール

注意

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

前提条件

  1. プライベートエージェントコンピューターにAzure PowerShell Az Module 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-cli ログイン コマンドを実行するときに使用されます。

  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 Patch 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 以降からアップグレードすることもできます。

注意

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

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

Azure Boards

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

Azure Repos

  • "TF401019: GitRepositoryNotFoundException"。

Azure Pipelines

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

Azure Test Plans

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

Azure Artifacts

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

Analytics

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

全般

  • 領域が不足している場合、左側のナビゲーション項目は IE で圧迫を取得します。

管理

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

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

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: ボードの特権の昇格の脆弱性

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

注意

データ移行ツールは、このリリースから約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 で利用できるようになりました。 詳細については 、ブログ を参照してください。

新しいナビゲーション

成果物に対する変更と Release Management 配置パイプラインライセンス

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

Azure SQL Database のサポート

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 の任意のサービスページで [/] をクリックするだけで、検索ボックスを呼び出すことができます。 この機能は、次のユーザーの に基づいて優先されています。

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

既定の検索ボックス

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

展開された検索ボックス

担当作業のポップアップ

私たちにとってすばらしい新機能は、 担当作業 のフライアウトです。 お客様が製品の一部を使用していて、別のパーツから情報を必要としている場合は、お客様のコンテキストを紛失することはありません。 この新機能を使用すると、製品のどこからでもこのフライアウトにアクセスできます。また、作業項目、プル要求、すべてのお気に入りなどの重要な情報をひとめで確認することができます。 この新しいフライアウトでは、コード内で リポジトリ のヘッドダウンが発生していて、次に作業する必要がある作業項目をすばやく確認する必要がある場合は、ポップアップをクリックして、自分に割り当てられている作業項目を確認し、次の項目を選択します。

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

担当作業のポップアップ

ここでは、Pr が割り当てられている2番目のピボットが表示されます。 フライアウトでは、さらに多くのプル要求を表示するために、1回のクリックでアクセスすることもできます。

担当作業ポップアップ PR

ここでは、最後の pivot が表示されます。これは、お気に入りているすべてのものです。 これには、お気に入りのチーム、ダッシュボード、ボード、バックログ、クエリ、リポジトリが含まれます。

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

Boards

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

コミットおよびプル要求を作業項目にリンクするのは簡単です。 次の構文を使用して、作業項目について説明します。

AB#{work item ID}

コミットメッセージ、プル要求のタイトル、またはプル要求の説明に作業項目を記述すると、その成果物へのリンクが Azure Boards によって作成されます。 たとえば、次のようなコミットメッセージを考えてみます。

Adds support for deleting connections. Fixes AB#20.

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

「開発」セクションを参照している Azure DevOps のスクリーンショット。

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

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

新しい作業項目ハブ

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

作業項目ハブ

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

作業項目ハブリスト

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

バックログ ハブは、ユーザーエクスペリエンスを向上させるために、3つのハブに分割されました。 しかし、従来のバックログハブは多くの機能を備えています。 これにより、多くの場合、ユーザーが探していた機能を見つけることが難しくなります。 この問題に対処するために、バックログハブを次のように分割しました。

  • バックログ ハブは、プロジェクトのバックログだけにホームになります。 バックログは、チームの作業の優先順位が付けられたリストです。 バックログは、作業項目階層、予測、新しいスプリント計画エクスペリエンスなどの計画ツールを提供します。
  • 新しい ボード ハブは、プロジェクトのすべてのかんばんボードに対してホームになります。 ボードは、ステータスとフローの通信に使用されます。 カード (作業項目) は、チームによって定義された列を通じて、ボード上で左から右に移動します。
  • 新しい スプリント ハブは、作業のインクリメントを計画および実行するために使用される機能のホームです。 各スプリントには、スプリントバックログ、taskboard、チームのキャパシティを管理および設定するためのビューが含まれています。

ボードハブ

新しいクエリハブ

新しいクエリハブを使用すると、古いハブからの既存のクエリ機能の多くを最新のルックアンドフィールで合理化できるだけでなく、重要なクエリを簡単に取得できる新しい機能が提供されます。 新しいエクスペリエンスには次のような特徴があります。

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

これらの魅力的な更新プログラムの詳細については、 DevOps のブログを参照してください。

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

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

スプリント計画機能

新しいスプリント計画機能は、スプリント計画のエクスペリエンスを迅速化および改善するのに役立ちます。

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

スプリント計画

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

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

  • 中断 したままにする この新しいセクションでは、最後に直接リンクしています (ボード |バックログ |スプリント) を使用しました。
  • お気に入り すべてのチームにおけるすべてのお気に入りボード、スプリント、バックログ。
  • マイ 所属するチームのすべてのボード、バックログ、およびスプリント。
  • すべて すべてのボード、バックログ、およびスプリントの完全な一覧。

ディレクトリページ

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

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

オプションの表示

これらの魅力的な更新プログラム、新しいチームプロファイルウィンドウ、およびお気に入りについては、 DevOps ブログを参照してください。

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

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

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

注釈の設定

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

注釈作業項目

有効な作業項目の種類をすばやく作成するには、カードのショートカットメニューを使用することもできます。

注釈の簡易作成

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

同じ領域またはイテレーションで作業することが一般的で、作業項目を移動するときに階層を繰り返し参照することができます。 区分 および イテレーション パスの制御には、最近使用した値のリストが 提案 として含まれるようになりました。設定と移動にすばやくアクセスできます。

区分のドロップダウンリスト

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

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

+/-を使用して、イテレーションスケジュール全体で作業をクエリします。 @CurrentIteration

@CurrentIterationチームがイテレーションスケジュールに基づいて作業を追跡するのに役立つマクロは、整数オフセットをサポートするようになりました。 -1 で閉じられていない作業のタブを簡単に保持する @CurrentIteration か、または + 1 を使用した将来のイテレーションに対して計画された作業を先に進め @CurrentIteration ます。 詳細については、Microsoft DevOps ブログの @CurrentIteration 投稿を参照してください。 この機能は、現時点では、456の投票を含む #12 最高の投票 候補 に基づいて優先順位が付けられました。

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

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

チームパラメーター

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

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

クエリエディターのチーム区分マクロ

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

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

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

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

作業項目のリンク

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

Repos

改善されたブランチピッカー

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

ブランチの選択

プル要求ポリシーがバイパスされたときに通知を受け取る

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

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

<a name="allow-bypassing-branch-policies-without-giving-up-push-protection">プッシュ保護を使用せずにブランチポリシーをバイパスできるようにする

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

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

  1. プル要求を完了するときにポリシーをバイパスします。 このアクセス許可を持つユーザーは、プル要求に対して "上書き" エクスペリエンスを使用できます。
  2. プッシュするときにポリシーをバイパスします。 このアクセス許可を持つユーザーは、必要なポリシーが構成されているブランチに直接プッシュできます。

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

注意

この変更によって動作が変更されることはありません。 以前 に許可さ れていたユーザーは、"ポリシーの適用から除外する" 権限が付与されます。これ により、 pr での完了を上書きし、ポリシーを使用してブランチに直接プッシュできるようになります。

詳細については、 ブランチの権限の設定 に関するドキュメントを参照してください。

コミットメッセージを使用してプル要求をすばやく記述する

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

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

既定のチームを持たないプル要求をレビュー担当者として作成する

最初にプル要求 (PR) エクスペリエンスを開始したときに、PR の作成時に選択したチームコンテキストにすべての Pr を割り当てることは理にかなっていると考えました。 チームコンテキストと PR 割り当ての間の接続が多くのメンバーに通知されていないため、この動作はフラストレーションポイントでした。 実際には、この記事の冒頭の 提案の1つです。

新しいナビゲーションの一部として、この既定の関連付けをチームに変更する機会がありました。 次の2つの変更点があります。

  1. PR の作成時に、既定ではレビュー担当者は追加されません。 レビュー担当者リストには、最近 Pr に追加された個人やグループを簡単に追加できるようにする機能があります。 また、 必要なレビュー担当者ポリシー を使用して、特定のレビュー担当者を追加して、コードをレビューすることもできます。
  2. プル要求 ハブには、新しいカスタマイズ可能なセクションがあります。 既定では、このセクションには "担当チームに割り当て済み" という Pr が表示され、以前のセクションと同等の機能が提供されます。 ただし、複数のチームに属している場合、このセクションには、チームに割り当てられた Pr が表示されます。 セクションはカスタマイズすることもできます。セクションヘッダーの近くにある [このビューをカスタマイズする] アクションをクリックするだけです。

テンプレートを使用したプル要求の説明の標準化

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

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

PR のテンプレートの追加

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

テンプレートを作成および使用する方法の詳細については、 プル要求テンプレート に関するドキュメントを参照してください。

プル要求のターゲットブランチを変更する

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

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

間違いを修正するだけでなく、ターゲットブランチを変更する機能によって、ターゲットブランチがマージまたは削除されたときにプル要求を "再ターゲット" することも簡単になります。 変更が依存している機能を含む PR が機能ブランチを対象としているシナリオについて考えてみます。 依存する変更内容を機能分岐の他の変更から分離してレビューする場合は、最初にを対象と features/new-feature します。 レビュー担当者は、変更内容だけを表示して、適切なコメントを残すことができます。

ここで、機能ブランチも PR がアクティブであり、変更前ににマージされた場合にどうなるかを考えてみましょう main 。 以前は、変更を破棄して新しい PR をに作成するか、PR をに main マージ features/new-feature してから、別の pr をからに作成する必要がありました features/new-feature 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 によって管理されているクラウドでホストされるインフラストラクチャ上で実行されるビルド/リリースエージェント。
プライベートエージェント 自己ホスト エージェント 提供および管理されているコンピューター上で実行されるビルド/リリースエージェント。
エージェントプール エージェントプール ビルドまたはリリースを実行できる、組織レベルのエージェントコンピューターのセット。
エージェントキュー エージェントプール ビルドまたはリリースを実行できる、プロジェクトレベルのエージェントコンピューターのセット。 組織レベルのエージェントプールにリンクされています。
ビルド定義 ビルド パイプライン アプリケーションのビルドステップのエンドツーエンドのセット。
Build Build またはが実行されているビルドパイプラインのインスタンス。
フェーズ ジョブ エージェントで順次または並列で実行される一連のタスク。 ビルドまたはリリースパイプラインには、1つのジョブまたは複数のジョブのグラフを含めることができます。
リリース定義 リリース パイプライン さまざまな段階にわたってアプリケーションをデプロイするための一連のリリース手順。
Release Release またはが実行されているリリースパイプラインのインスタンス。
環境 段階 リリースパイプラインから生成されたリリースを配置する場所を表す論理エンティティと独立したエンティティ。
同時実行ジョブ/パイプライン 並列ジョブ 並列ジョブを使用すると、組織内で一度に1つのビルドジョブまたはリリースジョブを実行できます。 より多くの並列ジョブを使用できるので、同時により多くのビルドジョブとリリースジョブを実行できます。
サービス エンドポイント サービス接続 外部サービスに接続してビルドまたはリリースのタスクを実行するために使用される、資格情報などの設定のグループ。

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

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

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

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

[フォルダー] ビューに移動して、組織およびセキュリティ用のフォルダーを作成します。 セキュリティはフォルダーレベルで設定できます。

リリースフォルダー

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

[新しいリリースの進行状況] ビューでは、デプロイの進行状況のライブ更新と、1回のクリックによる詳細へのアクセスが提供されます。 新しいビューではリリースパイプラインが視覚化されるため、発生している内容を理解しやすくなり、リリースのさまざまな段階で適切な詳細とアクションが表示されます。

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

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

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

環境は、その状態と詳細な進行状況を理解するための方法でモデル化されています。 任意の時点で、環境内の状態リンクをクリックしてログを取得できます。

環境

配置前と配置後

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

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

コミットと作業項目

各新しいリリースでは、環境をクリックすることで、各環境に関連するコミットと作業項目の一覧を個別に表示できます。 リストが長い場合は、フィルターを使用して、目的のコミットまたは作業項目を検索します。

リリースコミットと作業項目

配置の進行状況とログ

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

ログをクリックすると、フォーカスされたビューに入ることができます。

リリースログの詳細

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

テストハブのコンピューターグループは、TFS 2017 RTM で 非推奨 とされました。 Azure DevOps Server 2019 では、コンピューターグループサービスは使用できなくなりました。 これは、"Windows コンピューターのファイルコピー" タスクバージョン 1. * と "ターゲットコンピューターでの PowerShell" タスクバージョン 1. * のユーザーに影響します。 パイプラインが動作を続行するには、

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

テスト結果と拡張性

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

リリース テスト結果

既存の拡張機能は、この新しいビューで機能します。さらに、拡張機能を使用して、環境に関するさらに詳しい情報を表示する拡張ポイントが新たに追加されています。 詳細については、 投稿と拡張機能 のドキュメントを参照してください。

YAML を使用したビルドの構成

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

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

YAML

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

これで、別のビルドが正常に完了したときにビルドをトリガーできるようになりました。 アップストリームビルドによって生成された成果物は、後のビルドでダウンロードして使用できます。また、これらの変数からデータを取得することもできます。 BuildId, DefinitionId, 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 を使用して テスト結果の発行タスク またはテスト結果の発行を使用します。 今後、1つのエージェントを使用して、テストの実行のためにこのエクスペリエンスを拡張する予定です。

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

進行中のテストビュー

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

詳細なテストの概要

テストの実行のデバッグ詳細をページ全体に表示

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

ページ全体のデバッグ

コンテキスト内でのテスト履歴の表示

従来、チームは、テスト結果の履歴を表示するために、[ 実行 ハブ] に進む必要がありました。 新しいエクスペリエンスでは、ビルドとリリースの [ Test Plans ] タブ内にテストの履歴が表示されます。 テスト履歴情報は、選択されたテストの現在のビルド定義または環境から順番に提供され、その後にビルドとリリースの他の分岐と環境が続きます。

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

中止されたテストの表示

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

中止されたテストの表示

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

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

概要テスト結果の確認

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

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

テスト概要デバッグ

注意

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

パイプラインでのテスト分析の表示

正常なパイプラインを維持するには、時間の経過と共にテスト品質を追跡し、テスト資料を向上させることが重要です。 テスト分析機能は、ビルドとリリースパイプラインのテストデータをほぼリアルタイムで可視化します。 これにより、反復的な高影響品質の問題を特定することで、パイプラインの効率を向上させることができます。

さまざまな要素を使用してテスト結果をグループ化したり、ブランチまたはテストファイルの主要なテストを特定したり、特定のテストにドリルダウンして傾向を表示したり、無益などの品質の問題を把握したりすることができます。

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

テスト分析

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

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

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

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

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

リリースゲートパネル

ゲートが一貫して成功するまで配置を保持する

リリースゲートは、次の環境にリリースを昇格する前に、正常性条件の自動評価を有効にします。 既定では、すべてのゲートの成功したサンプルがすべて受信された後、リリースが進行します。 ゲートが不安定で、正常に受信したサンプルがノイズの場合でも、リリースは進行します。 このような問題を回避するために、リリースを構成して、進行状況の最小期間の整合性を確認できるようになりました。 実行時には、昇格を許可する前に、リリースによってゲートの連続した評価が成功することが保証されます。 評価の合計時間は「再評価までの時間」に依存し、通常は構成された最小期間よりも長くなります。 詳細については、ゲートのドキュメント を使用したリリースデプロイ制御 に関するドキュメントを参照してください。

ゲートの保持の設定

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

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

配置グループ

ビルド後の処理によってタグ付けされたビルドを継続的に配置します

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

ビルドタグトリガー

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

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

リリース変数

リリースの作成時に変数に指定された値は、そのリリースでのみ使用されます。 この機能を使用すると、ドラフトを作成するための複数の手順を回避し、draft で変数を更新し、変数を使用してリリースをトリガーすることができます。

リリースでの変数の解放

環境変数をタスクに渡す

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

環境変数を渡す

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

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

変数グループの複製

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

変数グループの複製

注意

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

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

リリースゲートは、次の環境にリリースを昇格する前に、正常性条件の自動評価を有効にします。 既定では、リリースパイプラインは、すべてのゲートが正常な状態である場合にのみ進行します。 場合によっては、リリースを高速化するときや、手動で正常性をチェックした後など、特定の状況では、承認者がゲートを無視し、そのゲートが正常として評価されていなくてもリリースを進行できるようにすることができます。 詳細については、 リリースゲート のドキュメントを参照してください。

ゲートを無視する

プル要求リリーストリガーを使用した追加のテストの実行

プル要求 (PR) に基づいてビルドをトリガーし、マージの前にすぐにフィードバックを取得できるようになりました。 リリースの PR トリガーも構成できるようになりました。 リリースの状態は、コードリポジトリにポストバックされ、PR ページに直接表示できます。 これは、PR ワークフローの一部として追加の機能または手動テストを実行する場合に便利です。

リリースの PR トリガー

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

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

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

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

Azure App Service Deploy タスク (4. *) のバージョンで Runfrompackage (旧称 runfrompackage) がサポートされるようになりました。

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

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

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

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

Azure App Service Deploy タスクの 4. * バージョンでは、 Linux で Azure Functionsする独自のカスタムコンテナーのデプロイがサポートされるようになりました。

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

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

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

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

Xcode 10

ヘルムを使用した Kubernetes へのデプロイの効率化

ヘルム は、Kubernetes アプリケーションのインストールと管理を合理化するツールです。 また、昨年、人気とコミュニティのサポートも増えてきました。 リリース のヘルムタスクを使用して、 Azure Container Service (AKS)またはその他の Kubernetes クラスターに対して、ヘルムグラフのパッケージ化と配置を行うことができるようになりました。

このヘルムタスクを追加することで、Kubernetes クラスターにコンテナーを配信するための、ヘルムベースの CI/CD パイプラインを設定できるようになりました。 詳細については、「 Deploy Using Kubernetes」 Azure Container Service を 参照してください。

ヘルムタスク

リリースで使用されるコントロールのヘルムバージョン

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

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

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

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

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

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

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

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

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

ブランチフィルター

外出先で作成されたアプリケーションの構築

ゴーツールインストーラー タスクを使用して、1つまたは複数のバージョンの実行ツールを即座にインストールします。 このタスクは、プロジェクトに必要な特定のバージョンのゴー Tool を取得し、ビルドエージェントのパスに追加します。 ターゲットの移動ツールのバージョンが既にエージェントにインストールされている場合、このタスクは、ダウンロードとインストールのプロセスをスキップします。

[ 実行] タスクを使用すると、アプリケーションの依存関係のダウンロード、ビルド、テストを行うことができます。 このタスクを使用して、任意のカスタムの [ジャンプ] コマンドを実行することもできます。

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

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

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

xcpretty は、xcodebuild 出力の読みやすさを高め、テスト結果を JUnit 形式で生成します。 Xcode build タスクは、ホストされている 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

Markdown ファイルを Git リポジトリから Wiki として発行する

開発者は、コードリポジトリ内の "Api"、"Sdk"、および "ヘルプドキュメントの説明" のドキュメントを作成します。 リーダーは、コードを使用して適切なドキュメントを見つける必要があります。 これで、コードリポジトリから markdown ファイルを発行し、Wiki でホストできるようになりました。

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

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

ページの発行ダイアログ

[ 発行] をクリックすると、選択したフォルダーにあるすべての markdown ファイルが wiki として公開されます。 これにより、ブランチの head が 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 が壊れている可能性のあるリンクを見つけて修正できるように、ページ内のリンクには markdown 構文を使用し、作業項目には wiki ページ リンクの種類を使用してください。 作業項目のテキスト形式の Url とハイパーリンクは、この機能によって取得されません。

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

ページ移動ダイアログ

次に、操作を実行する前に、 ページリンク作業項目 の一覧が表示されます。

ページリンクの移動

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

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

Wiki の目次

また、目次を挿入するには、ページの編集時に [書式] ペインの該当するボタンをクリックします。

Wiki TOC の挿入

Azure DevOps で markdown を使用する方法の詳細については、 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 リポジトリでホストされている markdown ファイルを wiki として公開するためのすべての要求に対してボトルネックを解消しました。 コードリポジトリに対する 投稿権限 だけがあれば、 wiki としてコードを発行 できます。

レポート

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

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

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

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

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

重要

XAML ビルドに関する洞察を探している場合は、引き続き以前のウィジェットを使用して、 xaml ビルドから新しいビルドへの移行についての説明を参照してください。 それ以外の場合は、新しいウィジェットに移動することをお勧めします。


フィードバック

皆様のご意見をお待ちしております。 問題を報告したり、アイデアを提供したり、 開発者コミュニティ から追跡したり、 Stack Overflowに関するアドバイスを受けたりすることができます。


ページのトップへ