ビルド パイプラインでの GitHub Enterprise のサポートと GitHub サービスの自動接続 - Sprint 146 Update
Azure DevOps の Sprint 146 Update では、GitHub と Azure Pipelines の統合が改善されました。 "新しいビルド パイプライン" ウィザードで、GitHub Enterprise リポジトリのパイプラインを作成できるようになりました。 リポジトリの分析も行い、推奨言語テンプレートを提供します。 さらに、選択した GitHub リポジトリのサービス接続を作成して再利用することもできます。
詳細については、以下の 機能 の一覧を参照してください。
機能
全般:
Azure Boards:
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
全般
削除済みプロジェクトの復元
この更新プログラムでは、Azure DevOps ポータルから削除されたプロジェクトを復元する機能を追加しました。 "プロジェクトの削除" アクセス許可がある場合は、[組織の設定>の概要] ページから削除されたプロジェクトを復元することもできます。
Azure Boards
Basic プロセスを使用した作業編成の効率化
重要
Basic プロセスは、米国中部リージョンで作成された新しい組織内の新しいプロジェクトの既定のプロセスとしてパブリック プレビュー段階にあります。
これまで、アジャイルは新しいプロジェクトの既定のプロセスであり、さまざまなプロジェクト配信方法に合わせて堅牢で柔軟な作業項目の種類と状態のセットを提供してきました。 他のツールに慣れているチームや、より強力なツール セットを採用したいチームは、よく知っている用語を使い始めたいと考えています。
新しい基本プロセスでは、作業を計画および追跡するための 3 種類の作業項目 (エピック、問題、タスク) が提供されます。 イシューを使用してユーザー ストーリー、バグ、機能などを追跡し、エピックを使用して問題をグループ化してより大きな作業単位にすることをお勧めします。 作業を進める際に、To Do、Doing、Done の単純な状態のワークフローに沿って項目を移動します。
新しいプロジェクトの 開始に役立つ問題とタスク の追跡に関するドキュメントを参照してください。
Azure Pipelines
パイプライン·ウィザードでの GitHub Enterprise サポート
以前は、ビジュアル デザイナーを使用して GitHub Enterprise リポジトリのパイプラインを作成できました。 これで、新しいビルド パイプライン ウィザードを 使用してパイプライン を作成することもできます。
ウィザードは GitHub Enterprise リポジトリを分析して、プロジェクト言語に一致する YAML テンプレートを提案します。 その後、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 アプリを使用した統合に関するページを参照してください。 複数のプラットフォームのジョブを含むパイプラインを設定するには、「マルチプラットフォーム パイプラインの作成」を参照してください。
GitHub における YAML リソースの既定の認可
GitHub でソース コードを管理し、YAML を使用してパイプラインを定義すると、リソース承認ビルドエラーが発生した可能性があります。 YAML ファイルを編集し、保護されたリソースの 1 つ (サービス接続、エージェント プール、変数グループ、セキュリティで保護されたファイルなど) への参照を追加した場合、Azure Pipelines はその変更を行い、ビルドに失敗したユーザーの ID を検証できませんでした。 この問題を回避するには、YAML ファイルを変更した後、Web エディターにビルド パイプラインを保存する必要がありました。 この問題が発生したユーザーの多くは、すべてのパイプラインでリソースの使用を許可したかっただけです。
リソース承認ビルドの失敗を回避するために、すべての新しいサービス接続、エージェント プール、変数グループの既定の動作を、すべてのパイプラインでの使用が承認されるように変更しました。 リソースをより厳密に制御する場合は、既定の承認モデルを無効にすることができます (下の図を参照)。 その場合、リソースを使用するアクセス許可を持つユーザーは、リソース参照が YAML ファイルに追加された後、Web エディターにパイプラインを保存する必要があります。
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 (統合およびパスワード) と接続文字列を使用したデータベースへの接続をサポートするように強化されました。
Grafana の注釈サービス フック
デプロイ完了イベントの Grafana 注釈を Grafana ダッシュボードに追加できる新しいサービス フックがサポートされるようになりました。 これにより、Grafana ダッシュボードで視覚化されるアプリケーションまたはインフラストラクチャ メトリックの変更とデプロイを関連付けることができます。
Azure Monitor アラートのクエリ タスク
以前のバージョンの Azure Monitors クエリ タスク では、クラシック監視エクスペリエンスでのみアラートのクエリがサポートされました。 この新しいバージョンのタスクでは、Azure Monitor によって最近導入された統合監視エクスペリエンスに関するアラートに対してクエリを実行できます。
Kubernetes へのデプロイ タスクにおける仕様ファイルのインライン入力
以前は、Kubernetes デプロイ タスクでは、構成のファイル パスを指定する必要があります。 これで、構成をインラインで追加することもできます。
Docker CLI インストーラー タスク
このタスクでは、ユーザーが指定したエージェントに任意のバージョンの Docker CLI をインストールできます。
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 に発行するために使用されます。 これまで、タスクは結果ファイルから結果を発行するだけで、結果ファイルに失敗したテストが含まれていてもビルドは失敗しません。 つまり、テストの失敗時にビルドを失敗させるためにカスタム手順を記述する必要がありました。
これで、失敗したテストがある場合にビルドを失敗させるオプションがタスクに追加されました。
Azure DevOps プロジェクトを作成するために Azure Portal に更新する
Azure Portal には、Azure DevOps プロジェクトの作成時に、より多くのフレームワークとサービスをサポートするための追加機能が追加されました。 各領域の変更の一覧を次に示します。
フレームワーク
Azure IoT は、クロスプラットフォーム IoT デバイス上でクラウド インテリジェンスをローカルに提供するフル マネージド サービスです。 これで、Azure Portal から Azure DevOps プロジェクトを作成し、アプリケーション フレームワークとして Simple IoT を使用できるようになりました。
サービス
以前は、Azure Portal の Azure DevOps プロジェクトの作成ワークフローでは、Kubernetes Service のオプションとして [新規作成] のみがサポートされました。 パイプラインセットアップのデプロイターゲットとして既存のクラスターを選択できるようにするための新しいオプションが追加されました。
Azure Portal を使用して CosmosDB データベースをセットアップしてデプロイする
現時点では、Azure Portal の Azure DevOps Project ワークフローを使用して、Git リポジトリのビルド パイプラインとリリース パイプラインを設定できます。 これで、これらのターゲットでアプリをバックアップするデータベースとしてプロビジョニングされた CosmosDB を使用して、Azure Web App for Containers (Linux) または Azure Kubernetes Service にデプロイできるようになりました。 これは現在、すべての Node.js テンプレートで使用できます。今後、他のテンプレートのサポートが追加される予定です。
Azure Portal で Functions のビルドとリリース パイプラインを設定する
Azure Portal で Azure DevOps Project ワークフローを使用して、Azure Functions 2.0 (Windows) をデプロイする Git リポジトリのビルド パイプラインとリリース パイプラインをセットアップできるようになりました。 これは、Node.js と .NET Core で使用できる機能です。
Azure Artifacts
パッケージの使用状況の統計
これまで、Azure Artifacts には、パッケージの使用状況や人気度を測定する方法が用意されていませんでした。 この更新プログラムでは、パッケージ一覧とパッケージの詳細ページの 両方にダウンロード と ユーザー の数を追加しました。 どちらのページの右側にも統計が表示されます。
Wiki
Wiki Markdown エディターのモノスペース フォント
Wiki Markdown エディター用のモノスペース フォントが導入されたので、読みやすさはもはや課題ではありません。 Markdown ソースはクリーンで読みやすく見えます。 この機能は、この提案チケットに基づいて優先順位が付けられます。
太字の Wiki ページ タイトル
以前は、Wiki ページのタイトルとヘッダー 1 の両方が同じように見えました。 これにより、読者が区別することが困難になりました。 これで、Wiki ページのタイトルは太字になり、ヘッダー 1 とは異なります。 この機能は、この提案チケットに基づいて優先順位が付けられます。
Markdown テーブルの挿入
Wiki で Markdown テーブルを作成することは、もはや難しい問題ではありません。 ボタンをクリックして Markdown テーブルを追加できるようになりました。 この機能は、この機能の提案チケットに基づいて優先順位が付けられます。
Wiki に Azure Boards クエリ結果を埋め込む
これで、テーブルの形式で Wiki ページに Azure Boards クエリ結果を埋め込むことができます。 次の図は、リリースされたすべての機能の一覧と、Wiki に埋め込まれている現在のスプリント内のすべてのアクティブなバグを含む Wiki ページのサンプルを示しています。 ページに表示されるコンテンツは、既存の作業項目クエリを使用しています。 この新機能を使用すると、動的コンテンツを作成することができ、Wikiページを手動で更新することを心配する必要はありません。
クエリ結果は、2 つの手順で追加できます。
- 編集ツール バーの [クエリ結果] ボタンをクリックします。
- 必要なクエリを選択し、[挿入] ボタンをクリックします。
ページを保存した後、クエリの結果をテーブルの形式で表示できるようになりました。
これは、次の機能の提案に基づいて優先順位付けされています。
次のステップ
Note
これらの機能は、今後 2 ~ 3 週間にわたってロールアウトされます。
以下の新機能について読み、Azure DevOps に進んで自分で試してみてください。
フィードバックの提供方法
これらの機能に関するご意見をお聞かせください。 フィードバック メニューを使用して、問題を報告したり、提案を提供したりします。
Stack Overflow のコミュニティからアドバイスや質問に回答してもらうこともできます。
よろしくお願いします。
Jeremy Epling
フィードバック
以下は間もなく提供いたします。2024 年を通じて、コンテンツのフィードバック メカニズムとして GitHub の issue を段階的に廃止し、新しいフィードバック システムに置き換えます。 詳細については、「https://aka.ms/ContentUserFeedback」を参照してください。
フィードバックの送信と表示