Azure DevOpsのSprint 146 Updateでは、GitHubとAzure Pipelinesの統合が改善されました。新規ビルドパイプラインウィザードでGitHub Enterpriseリポジトリ用のパイプラインを作成できるようになりました。あなたのリポジトリを分析して推奨する言語テンプレートを提供します。さらに、選択したGitHubリポジトリのサービス接続を作成および、再利用もできます。
詳細は以下の機能一覧をご覧ください。
Azure Boards:
Azure Pipelines:
- パイプラインウィザードでGitHub Enterpriseのサポート
- Pipelinesで、GitHubサービス接続を自動的に選択する
- GitHub Checksでそれぞれのパイプラインの状態を表示する
- GitHubでYAMLリソース参照のデフォルト認可の動作変更
- YAMLパイプライン用のサービスコンテナー
- Release SummaryでGitHubのコミットを作業項目として関連付ける
- YAMLに最適化された新しいAzure App Servicesタスク
- Azure SQLタスクでAzure Active Directory (AD)認証のサポート
- Grafana アノテーション用のサービスフック
- Query Azure Monitor alert タスク
- Kubernetes デプロイタスクでspecファイルをインラインで記述できるように
- Docker CLI Installer タスク
- Microsoft hosted agentsでのJava long-term support (LTS)の提供開始
- Bitbucket Cloud パイプライン向けのYAMLサポート
- pull request で複数のCIビルドのトリガーを避ける
- フォークされたリポジトリでのビルドでの、ビルド番号の変更、アーティファクトのアップロードおよび、ダウンロード
- Publish Test Results taskでテスト失敗したときにビルド失敗とする新しいオプションを追加
- Azure DevOps project作成用のAzure Portal更新
- Azure Portalで、CosmonDBデータベースの構築と展開を行う
- Azure PortalでAzure Functionsのビルドとリリースパイプラインをセットアップ
Azure Artifacts:
Wiki:
Administration:
重要
Basicプロセスは、米国中部(Central US)リージョンで作成された、新しい組織内の新しいプロジェクトのデフォルトプロセスとしてパブリックプレビューが行われています。
これまで、Agileが新しいプロジェクトのデフォルトプロセスであり、さまざまなプロジェクト配信方法に適した堅牢で柔軟な一連の作業項目の種類と状態を提供してきました。他のツールに慣れ親しんでいるとか、チームの成長により、さらに強力なツールセットを採用したいチームの中には、より慣れ親しんだ用語を使用してすぐに始めたいという人もいます。
新しいBasicプロセスは、作業を計画および追跡するための3つの作業項目タイプ(Epics, Issues, Tasks)が用意されています。ユーザーストーリー、バグ、機能などを追跡するためにissueを使用し、同時にEpicsを使用してissueをより大きな作業単位にまとめることをお勧めします。作業を進めながら、To Do、Doing、Doneという単純な状態のワークフローに沿ってアイテムを移動します。
あなたの新しいプロジェクトをより効果的にすすめるために、track issues and tasksのドキュメンテーションを見てください。
以前から、ビジュアルデザイナーを使用してGitHub Enterpriseリポジトリ用のパイプラインの作成ができていました。今回の強化で、New build pipelineウィザードでもパイプラインの作成ができるようになりました。
ウィザードはGitHub Enterpriseリポジトリを分析して、プロジェクト内の言語に合ったYAMLテンプレートを提案します。YAMLを編集してあなたのデフォルトブランチへの直接のコミット、あるいはpull requestとして保存できます。
詳細については、こちらにある、最初のパイプラインの作成に関するドキュメントを参照してください。
New build pipelineウィザードを使用してGitHub用のパイプラインを作成するとき、GitHubサービス接続を選択または作成するためのページにおいて、一覧から選択する接続について混乱を招いていました。今回の強化で、接続を選択しなくても良くなりました。ウィザードは、選択したリポジトリのサービス接続を自動的に作成して再利用します。
自動的に選択されているもの以外の接続を手動で選択する場合、Choose connectionハイパーリンクをクリックしてください。詳しくは、GitHubリポジトリの構築を参照してください。
重要
選択は、Azure Pipelines GitHub App(リポジトリにインストールされている場合)または、個人のGitHub ID(OAuthを使用)に基づいて行われます。
以前は、複数のプラットフォーム(Linux、macOS、Windowsなど)のジョブが含まれている場合でも、1つのビルドステータスだけがGitHub Checksに送信され、パイプラインを確認していました。今回の強化により、パイプライン内の各ジョブのGitHub Checksにステータスが投稿されるようになります。さらに、ビルド全体を再実行することも、GitHub Checksから失敗した個々のジョブだけを再実行できます。この機能を使用するには、Azure Pipelines GitHub Appを使用するようにパイプラインを構成する必要があります。詳細については、Integrate using the GitHub Appを参照してください。複数のプラットフォーム用のジョブを含むパイプラインを設定するには、Create a multi-platform pipelineを参照してください。
もし、GitHubでソースコードを管理して、パイプラインの定義にYAMLを使用すると、おそらくリソース承認ビルドが失敗することになります。YAMLファイルを編集して保護されているリソース(サービス接続、エージェントプール、変数グループ、セキュリティで保護されたファイルなど)のいずれかへの参照を追加した場合、Azure Pipelinesは変更を行いって、失敗したユーザーのIDを検証できません。ビルドこの問題を回避するには、YAMLファイルを変更した後、一度Webエディターでビルドパイプラインを保存する必要がありました。この問題に遭遇したユーザーの多くは、単にすべてのパイプラインにリソースの使用を許可することを望んでいました。
ビルド失敗のリソース参照の失敗を回避するために、すべての新しいサービス接続、エージェントプール、および変数グループのデフォルトの動作をすべてのパイプラインでの使用が認可されるように変更しました。リソースをより厳密に制御したい場合、デフォルトの承認モデルを無効にできます(下図を参照)。その場合、リソースを使用する権限を持つユーザーは、リソース参照がYAMLファイルに追加された後、Webエディターでパイプラインを保存する必要があります。
これまでは、YAMLパイプラインにおいて、データベースやメモリキャッシュといったサービスを使用していた場合、これらのサービスをインストール、開始、および停止する必要がありました。今回の更新で、これらのタスクを処理できるサービスコンテナーを追加しました。たとえば、統合テストのパイプラインでredis cacheを使用している場合、パイプラインのサービスとしてredisコンテナーイメージを含められるようになりました。エージェントは自動的にイメージを取得、起動してネットワークを有効にして、パイプラインの手順でredisのホスト名で参照できるようになります。パイプラインが完了すると、エージェントがサービスコンテナーをきれいにスピンダウンします。
昨年12月に、作業項目にGitHubのコミットをリンクできる機能が導入されました。GitHubのコミットにリンクされているすべてのAzure Boardの作業項目がリリース概要ページに表示されるようになりました。チームが環境へ展開されたコミットに関して、より多くの情報の追跡と、取得が可能となっています。
現代の開発者を念頭に置いてAzure App Servicesを展開するための簡単で強力な方法を提供する4つの新しいタスクをサポートします。これらのタスク向けに最適化されたYAML構文があり、WindowsプラットフォームとLinuxプラットフォームの両方で、WebApp、FunctionApp、WebApps for Containers、FunctionApp for ContainersなどのAzure AppServicesへの展開を簡単かつ直感的に理解できます。
また、ファイル変換とXMLおよびJSON形式の形式を置換するための新しいユーティリティタスクもサポートします。
Azure SQLタスクで、既存のSQLサーバー認証のサポートに加えて、Azure AD(統合されたパスワード)と接続文字列を使用したデータベースへの接続をサポートするように機能強化しました。
新しいサービスフックとして、Grafanaアノテーション用のDeployment Completedイベントをサポートしたので、展開結果をGrafanaダッシュボードへ追加できるようになりました。これにより、Grafanaダッシュボード上でアプリケーションの展開による変更および、インフラストラクチャーのメトリクスを関連付けられるようになります。
以前のバージョンのQuery Azure Monitors taskでは、アラートのクエリはクラッシック監視エクスペリエンスのみサポートしていました。この新しいバージョンのタスクでは、Azure Monitorに最近導入された統合された監視エクスペリエンスを使って、アラートのクエリが記述できます。
以前のKubernetes deploymentタスクでは、設定用のファイルパスを指定する必要がありました。今回の強化で、インラインで設定を追加できるようになりました。
このタスクでは、ユーザーの指定にしたがって、任意のバージョンのDocker CLIをエージェントにインストールできます。
以前は、Microsoft Hosted agentにJDKがプレインストールされていましたが、これは複雑なライセンス、エンドユーザーの制限、および長期的なサポートの欠如によって負債となっています。今回の更新では、JDKをAzul SystemsのOpenJDKのテスト済みかつ、認定済みのLTSビルドに置き換えました。Azureを使用するJava開発者は、Azul Systems Zulu EnterpriseによるOpenJDKのビルドを使用することにより、追加のサポートコストを負担することなく、本番用のJavaアプリケーションをビルドして実行できます。
この新しいオファーは、四半期ごとのセキュリティアップデートとバグ修正、および必要に応じて重要な定例外アップデートとパッチを組み込むことで、MicrosoftがホストするJavaのビルドおよびデプロイを安心して実行できるように設計されています。 現在オンプレミスまたは他のJDKを使用してJavaアプリケーションを構築または実行している場合、無料のサポートとメンテナンスのためにAzure上のZuluに移行することを検討してください。詳細については、ブログMicrosoft and Azul Systems bring free Java LTS support to Azureを参照してください。
以前のバージョンでは、YAMLベースのパイプラインにおいて、Bitbucket Cloudをサポートしていませんでした。今回の強化で、YAMLを使用してBitbucket Cloudパイプラインを定義することも、ビジュアルデザイナーを使用して依然と同じ操作にもできます。YAMLを使用するには、azure-pipelines.ymlファイルをリポジトリに追加してください。Azure Pipelinesで、New build pipelineを選択し、Use the visual designerを選択して、"Bitbucket Cloud"と"YAML"を選択します。ここにあなたのリポジトリのYAMLファイルへのパスの入力ができます。
詳しくは、YAML syntax guideとYAMLサンプルのGitHubリポジトリをご覧ください。
Azure Pipelinesに含まれているYAMLビルドテンプレートは、リポジトリ内の任意のブランチに対してビルドをトリガーするように構成されていました。これにはプルリクエストのトピックブランチが含まれています。その結果、pull requestが作成された場合に2つのビルドがトリガーされていました。1つは継続的統合トリガーに応答したpull requestブランチ用、もう1つはpull requestトリガーに応答したpull requestブランチ用です。
以下のYAMLスニペットを使用することで、組み込みのYAMLテンプレートはmasterブランチに対してのみ継続的インテグレーションビルドをトリガーするように設定されます。新しいpull requestは、pull requestトリガーを使用して構築されます。詳しくは、build pipeline triggerを参照してください。
trigger:
- master今まで、フォークされたリポジトリ用のpull request検証ビルドには、ビルドアーティファクトをアップロードおよびダウンロードしたり、ビルド番号を変更したりする権限がありませんでした。意図しないユーザーによってフォークされたリポジトリにおいて、トリガーされたビルド実行時、エージェントにより広い範囲の許可を利用可能にすることは安全ではなかったので、許可は制限されていました。今回の強化で、必要に応じてパイプラインでこれらの操作を実行できるように、エージェントのアクセス許可範囲が指定可能になりました。
以下は、tar.gzファイルのビルド出力をアーティファクトのステージングディレクトリにアーカイブする時実行するYAMLの例です。次は、ビルドに関連付けられるように、出力をAzure Pipelinesに発行します。詳しくは、Archive Files taskタスクおよびPublish Build Artifacts taskタスクに関する資料を参照してください。
- 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)'Publish Test Results taskは、選択したテストランナーでテストを実行後、テスト結果をAzure Pipelinesに発行する時使用されます。これまでは、タスクは結果ファイルから結果を単純に公開し、結果ファイルに失敗したテストが含まれていてもビルドに失敗することはありませんでした。このことは、テストの失敗時にビルドが失敗するようにカスタムステップを書かなければならない状態になっていました。
今回の強化で、テストに失敗した場合、ビルドを失敗させるオプションをタスクに追加しました。
Azureポータルで、Azure DevOpsプロジェクトを作成するときに、より多くのフレームワークとサービスをサポートする追加機能が行われました。以下は各エリアの変更点のリストです。
Azure IoTは、クロスプラットフォームのIoTデバイスでクラウドインテリジェンスをローカルに提供するフルマネージドなサービスです。これで、Azure PortalからAzure DevOpsプロジェクトを作成して、Simple IoTをアプリケーションフレームワークとして使用できます。
以前は、AzureポータルのCreate Azure DevOpsプロジェクトワークフローは、KubernetesサービスのオプションとしてCreate Newのみをサポートしていました。パイプライン設定の展開ターゲットとして既存のクラスターを選択できるようにするための新しいオプションが追加されました。
現在、Azure PortalのAzure DevOps Projectワークフローを使用して、Gitリポジトリのビルドおよびリリースパイプラインをセットアップできます。今回の強化でこれらのターゲット上のアプリをバックアップするデータベースとしてプロビジョニングされたCosmosDBを使用して、Azure Web App for Containers(Linux)またはAzure Kubernetes Serviceにデプロイできるようになりました。現在すべてのNode.jsテンプレートで利用可能であり、将来他のテンプレートのサポートを追加する予定です。
Azure PortalのAzure DevOps Projectワークフローを使用して、Azure Functions 2.0(Windows)を展開するGitリポジトリのビルドおよびリリースパイプラインが構築できるようになりました。これはNode.jsと.NET Coreで利用可能です。
これまで、Azure Artifactsにおいて、パッケージの使用状況や人気度を評価する方法を提供していませんでした。今回の更新で、パッケージリストとパッケージ詳細ページの両方に**Downloads(ダウンロード数)とUsers(ユーザー数)**を追加しました。どちらの統計情報もページの右側に表示されます。
Wiki Markdownエディター用の等幅フォントの導入により、読みづらいフォントで読むというチャレンジとはさよならです！。Markdownのソースはきれいで読みやすいように見えます。この機能は、この提案チケットに基づいて優先順位が付けられました。
以前は、WikiページのタイトルとHeader 1の両方が同じように見えました。これは読者がそれらを区別することを難しくしていました。今回の強化で、WikiページのタイトルはHeader 1とは異なり、太字で区別されています。この機能は、この提案チケットに基づいて優先順位が付けられています。
WikiでMarkdownテーブルを作成することは、もはや難題ではありません。ボタンをクリックするだけでMarkdownテーブルを追加できます。この機能は、この機能提案チケットに基づいて優先順位が付けられました。
Azure Boardsのクエリ結果をテーブル形式でWikiページに埋め込めます。以下の画像は、リリースされているすべての機能と、現在のスプリント内のすべてのアクティブなバグのリストがWikiに埋め込まれたWikiページのサンプルを示しています。ページに表示されているコンテンツは、既存の作業項目クエリを使用しています。この新機能を使用すると、動的コンテンツを作成でき、手動でWikiページを更新する必要はありません。
クエリ結果は2つのステップで追加できます。
- 編集ツールバーからQuery Resultsボタンをクリックします。
- 必要なクエリを選択してInsertボタンをクリックします。
ページを保存した後、クエリの結果はテーブルの形式で表示できます。
これは、次の機能提案に基づいて優先順位が付けられています。
今回のアップデートでは、Azure DevOpsポータルから削除されたプロジェクトを復元する機能が追加されました。「プロジェクトの削除」権限がある場合、Organization Settings > Overview Pageから削除したプロジェクトの復元ができます。ステップバイステップのガイダンスについては、こちらのドキュメントを参照してください。
注意事項
ここで議論されている機能は今後二～三週にわたって順次展開されます。
これらの新機能を読んだ後、次のリンクからぜひご自身でAzure DevOpsサービスを体験してみてください。
これらの機能についてどう思っているかお聞きしたいと思います。 フィードバックメニューを使用して問題を報告するか、提案を提出してください。
アドバイスや回答を必要とする質問がある場合、Stack Overflowコミュニティで聞いてください。
ありがとうございました。
Jeremy Epling