Azure Boards と Azure Pipelines の GitHub 統合の改善 - Sprint 149 Update

  • [アーティクル]

Azure DevOps の Sprint 149 Update では、GitHub コメントのメンションから直接 Azure Boards に移動する機能と、GitHub Enterprise での Azure Boards のサポートが追加されました。

Azure Pipelines では GitHub の pull request に新しい機能が追加され、コメント内で /azp をメンションするとオプションのチェックを実行できるようになりました。 パイプラインを実行する前に、リポジトリの共同作成者からの pull request に関するコメントを要求して、ビルドする前に不明なユーザーのコードを確認することもできます。

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

機能

General:

Azure Boards:

Azure Pipelines:

Azure Artifacts:

レポート:

全般

Azure Active Directory (Azure AD) の切断されたユーザーを解決する

スプリント 148 の更新プログラムにより、Azure DevOps ポータル内から組織を Azure Active Directory に接続する機能が提供されました。 この新しい簡略化されたエクスペリエンスにより、Azure portal で以前に必要だったいくつかの手順が保存されました。 ただし、接続プロセス中にアクセスを失ったメンバーのアクセス権を復元するためにサポートを呼び出さなければならなかったため、その新しいエクスペリエンスは大きなギャップを残しました。 新しく接続された Azure Active Directory で以前のログイン ID が見つからない場合、ユーザーはアクセスできなくなります。 このリリースでは、切断されたメンバーを自分で復元できるため、カスタマー サポートの呼び出しが節約され、生産性が向上します。

切断されたメンバーを復元するには、2 つの手順があります。 まず、これらのメンバーの現在の ID は、新しく接続された Azure AD の ID にマップされます。 一部の切断されたメンバーは Azure AD で一致する ID を持たない可能性があるため、2 番目の手順は、それらの再メインメンバーをゲストとして Azure AD に招待することです。 この更新プログラムは、Azure DevOps ポータルの Azure AD 設定ページから両方の手順を実行するためのインターフェイスを提供します。

このドキュメント で更新プログラムを探してください。

Azure Boards

ここで、構文を使用して AB#{work item ID} GitHub で問題、pull request、またはコミットのコメント内に作業項目をメンションすると、それらのメンションがハイパーリンクになり、クリックしてメンションされた作業項目に直接移動できます。

これにより、関連するすべての会話で Azure Boards の作業項目を乱雑にする正式なリンクは作成されませんが、代わりに、コードや顧客から報告された問題について説明しながら、作業項目に関する情報を少し提供する方法がチームに提供されます。 詳細については、 Azure Boards GitHub 統合 ドキュメントを参照してください。

Navigate to work items from mentions.

作業項目移行ルールへの更新

さまざまなプロセスと作業項目の種類間で一貫性のない複数の作業項目移行ルールをクリーンしました。 クローズ日、クローズ日、および状態変更日は、すべての標準作業項目タイプおよび新しくカスタマイズされた継承作業項目タイプで修正されました。 有効化日と有効化日は、すべてのシステム作業項目タイプに対して固定されますが、カスタマイズされた継承作業項目タイプでは固定されません。

Azure Boards の GitHub Enterprise サポート

Teams は、GitHub Enterprise Server インスタンスでホストされているリポジトリに Azure Boards プロジェクトを接続できるようになりました。 OAuth を使用して接続する場合は、リポジトリへの接続を作成する前に、OAuth アプリケーションの登録に関するドキュメントの手順に従ってください。

作業項目でのコメントの編集と削除

開発者コミュニティ フォーラムから、Azure Boards の作業項目のディスカッションのコメントを編集および削除できるようになりました。 コメントを編集するには、所有しているコメントの上にマウス ポインターを置くと、2 つの新しいボタンが表示されます。 鉛筆アイコンをクリックすると、編集モードに入り、編集を行い、[更新] ボタンを押して編集を保存できます。

Edit comments in Discussion.

オーバーフロー メニューをクリックすると、コメントを削除するオプションが表示されます。 これをクリックすると、このコメントを削除することを確認するメッセージが再度表示され、コメントが削除されます。

Delete comments in Discussion.

作業項目フォームの [履歴] タブには、編集および削除されたすべてのコメントの完全な監査証跡が表示されます。 また、ディスカッション エクスペリエンスの UI が更新され、よりモダンでインタラクティブな操作性が得られます。 さらに、コメントの周囲にバブルを追加して、個人のコメントの開始位置と終了位置を明確にしました。

作業項目フォームの状態値の順序

以前は、作業項目フォームの状態値はアルファベット順に並べ替えられていた。 この更新により、プロセス設定のワークフローの順序と一致するように状態値を並べ替える方法が変更されました。

New state value order.

Note

順序の変更は、Web および REST API のフォームにのみ影響します。 状態値の順序は、Visual Studio 2017 や Excel などの WIT クライアント OM を使用するクライアントでは変更されません。

Azure Pipelines

YAML パイプラインでチェックアウトされたコードのディレクトリを選択する

以前は、$(Agent.BuildDirectory) の下のディレクトリにリポジトリをsチェックしました。 これで、Git リポジトリが YAML パイプラインで使用するためにチェックされるディレクトリを選択できます。

キーワード (keyword)をpathcheckout使用すると、フォルダー構造を制御できます。 ディレクトリの指定に使用できる YAML コードの例を次に示します。

steps:
- checkout: self
  path: my-great-repo

この例では、コードがエージェントのワークスペース内のmy-great-repoディレクトリにチェックされます。 パスを指定しない場合、リポジトリは引き続き という名前sのディレクトリにチェックされます。

非公開プロジェクトのパイプライン ジョブごとの実行時間が 60 分に

これまでは、無料アカウント (つまり、並列ジョブを購入していなかったアカウント) は、1 か月あたり最大 1,800 分、一度に最大 30 分間ジョブを実行していました。 この更新プログラムでは、無料アカウントの制限を 30 分から 60 分に増やしました。

パイプラインを 60 分以上実行する必要がある場合は、並列ジョブごとに追加の容量を支払うか、セルフホステッド エージェントで実行できます。 セルフホステッド エージェントには、ジョブの長さの制限はありません。

ホストされたパイプライン イメージの更新

ホストされている Azure Pipelines の VS2017、Ubuntu 16.04、および Windows Container 1803 VM イメージの更新が行われました。 最新リリース の詳細については、こちらをご覧ください。 イメージで使用できるツールの詳細については、GitHub の Image Generation リポジトリを参照してください。

さらに、コンテナー ランタイムとして Moby を採用しました。 Moby は、カスタム コンテナー ベースのシステムにコンポーネントをアセンブリするために Docker によって作成されたオープン フレームワークです。 これにより、頻繁なアップストリーム パッチと機能強化をコンテナー ランタイムに提供できます。

ビルドおよびリリース パイプラインでの Duffle ツールのインストーラー タスク

Duffle は、クラウド ネイティブ アプリケーション バンドル (CNAB) をインストールして管理できるコマンド ライン ツールです。 CNAB を使用すると、コンテナーネイティブ アプリとそのサービスをバンドル、インストール、管理できます。

この更新プログラムでは、特定のバージョンの Duffle バイナリをインストールできるビルド パイプラインとリリース パイプラインの新しいタスクを追加しました。

Duffle tool installer task in build and release pipeline.

Slack からの Azure Pipelines 配置の承認

これまで、Slack ユーザーはチャネル内からリリースデプロイを管理する機能が限られていた。 Slack 用 Azure Pipelines アプリを使用すると、チャネルからのリリース デプロイを承認または拒否できます。 これにより、Azure Pipelines ポータルに強制的に移動する必要がないため、承認プロセスが簡単になります。 さらに、Slack モバイル アプリを使用して、外出先でデプロイを承認できます。

Approve Azure Pipelines deployments from Slack.

Azure Pipelines と Slack の詳細については、こちらのドキュメント を参照してください。

新しいビルド パイプライン ウィザードにすべてのソース プロバイダーが組み込まれる

これまで、GitHub、Azure Repos、Bitbucket Cloud などのソース プロバイダーは、クラシック パイプライン エディターと新しいパイプライン ウィザードの間で分割されていました。 この更新プログラムでは、1 つの開始点に対して、それらすべてを新しいパイプライン ウィザードに追加しました。 ページの下部にあるリンクをクリックしても、クラシック エディターで YAML なしでパイプラインを作成できます。

All source providers included in the new build pipeline wizard.

GitHub コメントのトリガーの最適化

GitHub pull request コメントを使用してビルドをトリガーするチームのエクスペリエンスが向上しました。 通常、セキュリティのために、これらのチームは pull request を自動的に作成することを望んでいません。 代わりに、チーム メンバーが pull request を確認し、安全であると判断されたら、pull request コメントを使用してビルドをトリガーします。 新しい設定では、チーム メンバーに対してのみ自動プル要求ビルドを許可しながら、このオプションを保持します。

GitHub comments trigger optimizations.

CTest と PHPUnit のテスト結果を発行する

この更新プログラムにより、パイプラインで CTest 実行からテスト結果を発行するためのサポートが追加されました。 CTest 結果を発行するには、[テスト結果の発行] タブの [テスト結果形式] 入力で [CTest] オプションを選択します。

Publish CTest and PHPUnit test results.

さらに、PHPUnit テスト実行の発行も含まれています。 JUnit の結果形式は常にサポートされていますが、PHPUnit の特定のコンストラクトを利用できるようになりました。 テスト結果の公開の詳細については、こちらのドキュメント を参照してください。

Azure Artifacts

Maven 向けアップストリーム ソース

Maven フィードでアップストリーム ソースを使用できるようになりました。 これには、プライマリ Maven Central リポジトリと Azure Artifacts フィードが含まれます。 Maven アップストリームを既存のフィードに追加するには、フィード設定にアクセスし、[アップストリーム ソース] ピボットを選択してから、[アップストリーム ソースの追加] を選択します。

Upstream sources for Maven.

報告

テスト エンティティ セットに対する Analytics サービスの OData バージョンの変更

Azure DevOps の Analytics サービスは、OData を使用してサポートされているブラウザーから直接クエリを実行できるエンティティ セットで構成されます。 このサービスには、_odata要素に追加できるバージョン管理された OData API が用意されています。

この更新プログラムでは、テスト エンティティ セットをバージョン 3.0-preview に移行します。 OData 2.0-preview バージョン エンドポイントを使用している場合は、破壊的変更を防ぐためにバージョン 3.0-preview に変更する必要があります。

次の一覧には、バージョン 3.0-preview に移行されるエンティティ セットが含まれています。

  • TestRuns
  • Testresults
  • テスト
  • ビルド
  • ブランチ
  • リリース
  • ReleaseEnvironments
  • TestResultsDaily
  • ReleasePipelines
  • ReleaseStages
  • BuildPipelines

Analytics サービスで OData エンドポイントを使用する方法の詳細については、こちらのドキュメントを参照 してください。

次のステップ

Note

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

Azure DevOps に向かい、見てみましょう。

Azure DevOps に移動する

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

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

Make a suggestion

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

よろしくお願いします。

Chris Patterson