次の方法で共有

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 に関するコメントを要求して、ビルドする前に不明なユーザーのコードを確認することもできます。

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

機能

全般:

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 統合 ドキュメントを参照してください。

メンションから作業項目に移動します。

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

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

Azure Boards の GitHub Enterprise サポート

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

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

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

ディスカッションのコメントを編集します。

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

ディスカッションのコメントを削除します。

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

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

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

新しい状態値の順序。

Note

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

Azure Pipelines

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

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

checkoutで path キーワードを使用すると、フォルダー構造を制御できます。 ディレクトリの指定に使用できる 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 hereの Image Generation リポジトリを参照してください。

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

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

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

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

ビルドおよびリリース パイプラインのダフル ツール インストーラー タスク。

Slack からの Azure Pipelines 配置の承認

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

Slack から Azure Pipelines デプロイを承認します。

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

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

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

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

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

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

GitHub コメントは最適化をトリガーします。

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

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

CTest と PHPUnit のテスト結果を発行します。

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

Azure Artifacts

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

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

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 に移動する

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

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

ご提案の送信

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

よろしくお願いします。

Chris Patterson