Azure Pipelines - Sprint 146 Update

特徴

パイプライン ウィザードでのサポートのGitHub Enterprise

以前は、ビジュアル デザイナーを使用して、GitHub Enterprise リポジトリのパイプラインを作成できました。 これで、 新しいビルド パイプライン ウィザードを使用してパイプラインを作成することもできます。

GitHub Enterprise support in the pipeline wizard.

ウィザードは、GitHub Enterprise リポジトリを分析して、プロジェクト言語に一致する YAML テンプレートを提案します。 その後、既定のブランチへの直接コミットとして、またはプル要求として YAML を編集して保存できます。

Edit and save the YAML.

詳細については、最初のパイプラインの作成に関するドキュメントを 参照してください

パイプラインでのサービス接続の自動GitHub

新しいビルド パイプライン ウィザードを使用してGitHub用のパイプラインを作成すると、GitHub サービス接続を選択または作成するためのページが、一覧から選択する接続について混乱を招きました。 これで、接続を選択する必要はありません。 ウィザードによって、選択したリポジトリのサービス接続が自動的に作成され、再利用されます。

自動的に選択される接続以外の接続を手動で選択する場合は、[ 接続の選択 ] ハイパーリンクに従います。 詳細については、「GitHub リポジトリのビルド」を参照してください。

注意

選択は、Azure Pipelines GitHub アプリ (リポジトリにインストールされている場合) または個人のGitHub ID (OAuth を使用) に基づいています。

GitHub チェックで各パイプライン ジョブの状態を表示する

以前は、複数のプラットフォーム (Linux、macOS、Windows など) のジョブが含まれている場合でも、1 つのビルド状態が GitHub パイプラインのチェックに投稿されていました。 次に、パイプライン内の各ジョブのGitHubチェックに状態がポストされます。 さらに、ビルド全体を再実行することも、GitHubチェックから失敗した個々のジョブのみを再実行することもできます。 この機能を使用するには、Azure Pipelines GitHub アプリを使用するようにパイプラインを構成する必要があります。 詳細については、「GitHub アプリを使用した統合」を参照してください。 複数のプラットフォームのジョブを使用してパイプラインを設定するには、「 マルチプラットフォーム パイプラインを作成する」を参照してください。

Display status for each pipeline job.

GitHubでの YAML リソースの既定の承認

GitHubでソース コードを管理し、YAML を使用してパイプラインを定義すると、リソース承認ビルドエラーが発生した可能性があります。 YAML ファイルを編集し、保護されたリソースの 1 つ (サービス接続、エージェント プール、変数グループ、セキュリティで保護されたファイルなど) への参照を追加Azure Pipelines、その変更を行ってビルドに失敗したユーザーの ID を検証できませんでした。 この問題を回避するには、YAML ファイルを変更した後、Web エディターにビルド パイプラインを保存する必要がありました。 この問題が発生したユーザーの多くは、すべてのパイプラインにリソースの使用を許可することを望んでいました。

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

Default authorization for YAML resources.

YAML パイプライン用のサービス コンテナー

以前は、YAML パイプラインでこれらのサービスが使用されている場合は、データベースやメモリ キャッシュなどのサービスをインストール、開始、停止する必要がありました。 この更新プログラムでは、これらのタスクを処理できる サービス コンテナー を追加しました。 たとえば、パイプラインで統合テストに redis キャッシュを使用する場合、redis コンテナー イメージをサービスとしてパイプラインに含めることができます。 エージェントは、イメージを自動的にフェッチし、起動してネットワークを作成し、パイプラインステップでホスト名 redis で参照できるようにします。 パイプラインが完了すると、エージェントはサービス コンテナーをクリーンにスピンダウンします。

リリースの概要でGitHubコミットにリンクされている作業項目

12 月に、GitHubコミットを作業項目にリンクする機能が導入されました。 リリースの概要ページで、GitHubコミットにリンクされているすべてのAzure Boards作業項目が表示されることをお知らせします。 これにより、チームは環境にデプロイされたコミットに関する詳細情報を追跡および取得できます。

YAML 用に最適化された新しいAzure App Service タスク

現在、最新の開発者を念頭に置いてAzure アプリサービスを展開するための簡単で強力な方法を提供する 4 つの新しいタスクがサポートされるようになりました。 これらのタスクには最適化された YAML 構文があるため、Windows と Linux プラットフォームの両方で WebApps、FunctionApps、WebApps for Containers、FunctionApps for Containers など、Azure AppServices へのデプロイを簡単かつ直感的に作成できます。

また、XML 形式と JSON 形式のファイル変換と変数の置換のための新しいユーティリティ タスクもサポートしています。

Azure SQL タスクの Azure Active Directory (AD) 認証のサポート

Azure SQL タスクは、Azure AD (統合&パスワード) と接続文字列を使用したデータベースへの接続と、SQL サーバー認証の既存のサポートをサポートするように強化されました。

Azure AD authentication support for Azure SQL task.

Grafana 注釈サービス フック

デプロイ完了イベントの Grafana 注釈を Grafana ダッシュボードに追加できる新しいサービス フックがサポートされるようになりました。 これにより、デプロイを、Grafana ダッシュボードで視覚化されているアプリケーションまたはインフラストラクチャ メトリックの変更と関連付けることができます。

Grafana annotations service hook.

Azure Monitor アラート タスクのクエリを実行する

以前のバージョンの Azure Monitors クエリ タスクでは、クラシック監視 エクスペリエンスに対してのみアラートのクエリを実行できるようになりました。 この新しいバージョンのタスクでは、Azure Monitor によって最近導入された統合監視エクスペリエンスに関するアラートを照会できます。

Query Azure Monitor alerts tasks.

Kubernetes へのデプロイ タスクでの spec ファイルのインライン入力

以前は、Kubernetes デプロイ タスクでは、構成のファイル パスを指定する必要があります。 これで、構成をインラインで追加することもできます。

Inline input of spec file in Deploy to Kubernetes task.

Docker CLI インストーラー タスク

このタスクでは、ユーザーが指定したエージェントに任意のバージョンの Docker CLI をインストールできます。

Docker CLI Installer task.

Microsoft ホスト型エージェントでの Java 長期サポート (LTS)

以前は、Microsoft でホストされていたエージェントには、複雑なライセンス、エンドユーザーの制限、長期的なサポートの欠如によって過負荷になった JDK がプレインストールされていました。 この更新プログラムでは、JDK を Azul Systems の OpenJDK のテスト済み、認定済み LTS ビルドに置き換えました。 Azure を使用する Java 開発者は、追加のサポート コストを発生させることなく、Azul Systems Zulu Enterprise ビルドの OpenJDK を使用して運用 Java アプリケーションをビルドして実行できるようになりました。

この新しいオファリングは、四半期ごとのセキュリティ更新プログラムとバグ修正プログラム、および必要に応じて重要な帯域外更新プログラムとパッチを組み込むことで、Microsoft がホストする Java のビルドとデプロイを心配なくするように設計されています。 現在、オンプレミスまたは他の JDK を使用して Java アプリをビルドまたは実行している場合は、無料のサポートとメンテナンスのために Azure 上の Zulu に移行することを検討してください。 詳細については、 Microsoft と Azul Systems が Azure に Java LTS の無料サポートを提供するブログを参照してください

Bitbucket Cloud パイプラインの YAML サポート

以前は、 YAML ベースのパイプラインは Bitbucket Cloud をサポートしていませんでした。 これで、YAML を使用して Bitbucket Cloud パイプラインを定義するか、ビジュアル デザイナーを使用して同じ操作を行うことができます。 YAML を使用するには、 azure-pipelines.yml ファイルをリポジトリに追加します。 Azure Pipelinesで、[新しいビルド パイプライン] を選択し、[ビジュアル デザイナーのハイパーリンクを使用する] を選択し、[Bitbucket Cloud] と [YAML] を選択します。 ここでは、リポジトリの YAML ファイルへのパスを入力できます。

詳細については、YAML 構文ガイドと YAMLサンプルのGitHubリポジトリを参照してください。

プル要求に対して複数の CI ビルドをトリガーしないようにする

Azure Pipelinesに含まれる YAML ビルド テンプレートは、リポジトリ内の任意のブランチのビルドをトリガーするように構成されました。 これには、pull request トピックブランチが含まれていました。 その結果、プル要求が作成されたときに 2 つのビルドがトリガーされました。 継続的インテグレーション トリガーに応答する pull request ブランチの 1 つのビルドと、プル要求トリガーに応答する pull request ブランチの 2 つ目のビルド。

以下の YAML スニペットを使用すると、組み込みの YAML テンプレートが 、マスター ブランチに対してのみ継続的インテグレーション ビルドをトリガーするように構成されます。 新しいプル要求は引き続き pull request トリガーを使用してビルドされます。 詳細については、 ビルド パイプライン トリガー のドキュメントを参照してください。

trigger:
- master

フォークされたリポジトリ ビルドでのビルド番号の変更、成果物のアップロードとダウンロード

これまで、フォークされたリポジトリのプル要求検証ビルドには、ビルド成果物をアップロードしてダウンロードしたり、ビルド番号を変更したりするためのアクセス許可がありませんでした。 不明なユーザーによってトリガーされるフォーク ビルド中にエージェントのより広範なスコープのアクセス許可を使用できるようにするため、アクセス許可が制限されました。 この更新プログラムでは、必要に応じてパイプラインでこれらの操作を実行できるように、エージェントのアクセス許可のスコープが設定されます。

tar.gz ファイル内のビルド出力を成果物ステージング ディレクトリにアーカイブするために使用できる YAML の例を次に示します。 次に、ビルドに関連付けるAzure Pipelinesに出力を発行します。 詳細については、アーカイブ ファイル タスクビルドの発行Artifactsタスクに関するドキュメントを参照してください。

- task: ArchiveFiles@2
  inputs:
    archiveType: 'tar'
    tarCompression: 'gz'
    includeRootFolder: false
    rootFolderOrFile: '$(build.sourcesDirectory)/target'
    archiveFile: '$(build.artifactStagingDirectory)/$(build.buildId).tar.gz'
- task: PublishBuildArtifacts@1
  inputs:
    pathtoPublish: '$(build.artifactStagingDirectory)'

失敗したテストでビルドに失敗するテスト結果の発行タスクの新しいオプション

テスト結果の発行タスクは、選択したテスト ランナーを使用してテストが実行されたときにテスト結果をAzure Pipelinesに発行するために使用されます。 これまで、タスクは結果ファイルから結果を発行するだけで、結果ファイルに失敗したテストが含まれていてもビルドに失敗しません。 これは、テストエラー時にビルドを失敗させるためにカスタムステップを記述する必要があることを意味しました。

これで、失敗したテストがある場合にビルドを失敗させるオプションがタスクに追加されました。

Fail the build if there are any failed tests.

Azure DevOps プロジェクトを作成するための Azure Portal の更新

Azure Portal には、Azure DevOps プロジェクトを作成するときに、より多くのフレームワークとサービスをサポートするための追加機能が含まれるようになりました。 各領域の変更の一覧を次に示します。

フレームワーク

Azure IoTは、クロスプラットフォーム IoT デバイスでクラウド インテリジェンスをローカルに提供するフル マネージド サービスです。 これで、Azure Portal からAzure DevOps プロジェクトを作成し、アプリケーション フレームワークとして Simple IoT を使用できるようになりました。

Use the Simple IoT as the application framework.

サービス

以前は、Azure Portal のAzure DevOps Project作成ワークフローでは、Kubernetes Service のオプションとして [新規作成] のみがサポートされています。 パイプラインセットアップのデプロイターゲットとして既存のクラスターを選択できるようにするための新しいオプションが追加されました。

Choose an existing cluster as the deployment target for the pipeline setup.

Azure Portal を使用して CosmosDB データベースをセットアップしてデプロイする

現在、Azure Portal のAzure DevOps Project ワークフローを使用して、Git リポジトリのビルド パイプラインとリリース パイプラインをセットアップできます。 これで、Azure Web App for Containers (Linux) にデプロイすることも、これらのターゲット上のアプリをバックアップするデータベースとして CosmosDB をプロビジョニングしてAzure Kubernetes Serviceすることもできます。 現在、これはすべてのNode.js テンプレートで使用でき、今後、他のテンプレートのサポートを追加する予定です。

Use the Azure Portal to set up and deploy to an Azure Cosmos DB database.

Azure Portal での Functions のビルドとリリース パイプラインのセットアップ

これで、Azure Portal の Azure DevOps Project ワークフローを使用して、Azure Functions 2.0 (Windows) をデプロイする Git リポジトリのビルド パイプラインとリリース パイプラインをセットアップできるようになりました。 これは、Node.js および .NET Core で使用できる機能です。

Set up builds and release pipelines for Functions in Azure portal.

次のステップ

Note

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

以下の新機能についてお読みになり、Azure DevOpsに進んで自分で試してみてください。

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

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

Make a suggestion

また、Stack Overflow のコミュニティからアドバイスや質問を受け取ることもできます。

よろしくお願いします。

Jeremy Epling