Azure Pipelines - Sprint 149 Update

機能

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 の特定のコンストラクトを利用できるようになりました。 テスト結果の公開の詳細については、こちらのドキュメント を参照してください

次のステップ

Note

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

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

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

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

Make a suggestion

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

よろしくお願いします。

Chris Patterson