ビルドパイプラインでの GitHub Enterprise のサポートと GitHub サービスの自動接続 - Sprint 146 Update

[アーティクル]
12/08/2023

Azure DevOps の Sprint 146 Update では、GitHub と Azure Pipelines の統合が改善されました。 "新しいビルドパイプライン" ウィザードで、GitHub Enterprise リポジトリのパイプラインを作成できるようになりました。リポジトリの分析も行い、推奨言語テンプレートを提供します。さらに、選択した GitHub リポジトリのサービス接続を作成して再利用することもできます。

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

機能

全般:

削除済みプロジェクトの復元

Azure Boards:

Basic プロセスを使用した作業編成の効率化

Azure Pipelines:

パイプライン·ウィザードでの GitHub Enterprise サポート
パイプラインでの自動 GitHub サービス接続
GitHub Checks での各パイプラインジョブの状態の表示
GitHub における YAML リソースの既定の認可
YAML パイプラインのサービスコンテナー
リリース概要で作業項目が GitHub コミットにリンクされる
YAML に合わせて最適化された新しい Azure App Service タスク
Azure SQL タスクに対する Azure Active Directory (AD) 認証のサポート
Grafana の注釈サービスフック
Azure Monitor アラートのクエリタスク
Kubernetes へのデプロイタスクにおける仕様ファイルのインライン入力
Docker CLI インストーラータスク
Microsoft ホステッドエージェント上での Java 長期サポート (LTS)
Bitbucket Cloud パイプラインの YAML サポート
pull request に対して複数の CI ビルドがトリガーされることの回避
フォークされたリポジトリビルドでのビルド番号の変更、成果物のアップロードとダウンロード
テストエラー発生時にビルドが失敗するようにする、テスト結果の発行タスクの新しいオプション
Azure DevOps プロジェクトを作成するために Azure Portal に更新する
Azure Portal を使用して CosmosDB データベースをセットアップしてデプロイする
Azure Portal で Functions のビルドとリリースパイプラインを設定する

Azure Artifacts:

パッケージの使用状況の統計

Wiki

Wiki Markdown エディターのモノスペースフォント
太字の Wiki ページタイトル
Markdown テーブルの挿入
Wiki に Azure Boards クエリ結果を埋め込む

全般

削除済みプロジェクトの復元

この更新プログラムでは、Azure DevOps ポータルから削除されたプロジェクトを復元する機能を追加しました。 "プロジェクトの削除" アクセス許可がある場合は、[組織の設定>の概要] ページから削除されたプロジェクトを復元することもできます。

Azure Boards

Basic プロセスを使用した作業編成の効率化

重要

Basic プロセスは、米国中部リージョンで作成された新しい組織内の新しいプロジェクトの既定のプロセスとしてパブリックプレビュー段階にあります。

これまで、アジャイルは新しいプロジェクトの既定のプロセスであり、さまざまなプロジェクト配信方法に合わせて堅牢で柔軟な作業項目の種類と状態のセットを提供してきました。他のツールに慣れているチームや、より強力なツールセットを採用したいチームは、よく知っている用語を使い始めたいと考えています。

新しい基本プロセスでは、作業を計画および追跡するための 3 種類の作業項目 (エピック、問題、タスク) が提供されます。イシューを使用してユーザーストーリー、バグ、機能などを追跡し、エピックを使用して問題をグループ化してより大きな作業単位にすることをお勧めします。作業を進める際に、To Do、Doing、Done の単純な状態のワークフローに沿って項目を移動します。

Organize work using the Basic process.

新しいプロジェクトの開始に役立つ問題とタスクの追跡に関するドキュメントを参照してください。

Azure Pipelines

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

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

GitHub Enterprise support in the pipeline wizard.

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

Edit and save the YAML.

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

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

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

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

Note

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

GitHub Checks での各パイプラインジョブの状態の表示

以前は、複数のプラットフォーム (Linux、macOS、Windows など) のジョブが含まれている場合でも、1 つのビルド状態が GitHub Checks に投稿されました。これで、パイプライン内の各ジョブの状態が 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 Cache を使用する場合は、Redis コンテナーイメージをサービスとしてパイプラインに含めることができます。エージェントはイメージを自動的にフェッチし、起動してネットワークを作成し、パイプラインステップがホスト名 redis で参照できるようにします。パイプラインが完了すると、エージェントはサービスコンテナーをクリーンにスピンダウンします。

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

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

YAML 用に最適化された新しい Azure アプリサービスタスク

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

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

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

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

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 へのデプロイタスクにおける仕様ファイルのインライン入力

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

Inline input of spec file in Deploy to Kubernetes task.

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

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

Docker CLI Installer task.

Microsoft ホステッドエージェント上での Java 長期サポート (LTS)

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

pull request に対して複数の CI ビルドがトリガーされることの回避

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

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

trigger:
- main

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

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

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

- 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 プロジェクトの作成ワークフローでは、Kubernetes Service のオプションとして [新規作成] のみがサポートされました。パイプラインセットアップのデプロイターゲットとして既存のクラスターを選択できるようにするための新しいオプションが追加されました。

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

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

現時点では、Azure Portal の Azure DevOps Project ワークフローを使用して、Git リポジトリのビルドパイプラインとリリースパイプラインを設定できます。これで、これらのターゲットでアプリをバックアップするデータベースとしてプロビジョニングされた CosmosDB を使用して、Azure Web App for Containers (Linux) または 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.

Azure Artifacts

パッケージの使用状況の統計

これまで、Azure Artifacts には、パッケージの使用状況や人気度を測定する方法が用意されていませんでした。この更新プログラムでは、パッケージ一覧とパッケージの詳細ページの 両方にダウンロード と ユーザー の数を追加しました。どちらのページの右側にも統計が表示されます。

Package usage stats.

Wiki

Wiki Markdown エディターのモノスペースフォント

Wiki Markdown エディター用のモノスペースフォントが導入されたので、読みやすさはもはや課題ではありません。 Markdown ソースはクリーンで読みやすく見えます。この機能は、この提案チケットに基づいて優先順位が付けられます。

Monospaced font for Wiki Markdown editor.

太字の Wiki ページタイトル

以前は、Wiki ページのタイトルとヘッダー 1 の両方が同じように見えました。これにより、読者が区別することが困難になりました。これで、Wiki ページのタイトルは太字になり、ヘッダー 1 とは異なります。この機能は、この提案チケットに基づいて優先順位が付けられます。

Bold Wiki page titles.

Markdown テーブルの挿入

Wiki で Markdown テーブルを作成することは、もはや難しい問題ではありません。ボタンをクリックして Markdown テーブルを追加できるようになりました。この機能は、この機能の提案チケットに基づいて優先順位が付けられます。

Insert Markdown table.

Wiki に Azure Boards クエリ結果を埋め込む

これで、テーブルの形式で Wiki ページに Azure Boards クエリ結果を埋め込むことができます。次の図は、リリースされたすべての機能の一覧と、Wiki に埋め込まれている現在のスプリント内のすべてのアクティブなバグを含む Wiki ページのサンプルを示しています。ページに表示されるコンテンツは、既存の作業項目クエリを使用しています。この新機能を使用すると、動的コンテンツを作成することができ、Wikiページを手動で更新することを心配する必要はありません。

Embed Azure Boards query results in Wiki.

クエリ結果は、2 つの手順で追加できます。

編集ツールバーの [クエリ結果] ボタンをクリックします。

Select the Query Results button from the edit toolbar.

必要なクエリを選択し、[挿入] ボタンをクリックします。

ページを保存した後、クエリの結果をテーブルの形式で表示できるようになりました。

View results of the query.

これは、次の機能の提案に基づいて優先順位付けされています。

次のステップ

Note

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

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

Azure DevOps に移動する

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

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

Make a suggestion

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

よろしくお願いします。

Jeremy Epling

次の方法で共有

ビルドパイプラインでの GitHub Enterprise のサポートと GitHub サービスの自動接続 - Sprint 146 Update

機能