Azure DevOpsのSprint 149 Updateでは、GitHubコメントの記載から直接Azure Boardsに移動する機能と、GitHub EnterpriseでのAzure Boardsのサポートを追加しました。
Azure Pipelinesでは、コメントに /azp を付けてオプションチェックを実行できるようにするGitHubプルリクエストの新機能を有効にしました。 パイプラインが実行される前に、リポジトリコントリビュータからのpull requestについてコメントの要求ができます。それにより、ビルドする前に未知のユーザからのコードをレビューができます。
詳細については、以下の機能リストをご覧ください。
Azure Boards:
- GitHubコメントでAzure Boardsの作業項目を直接遷移する
- 作業項目の移行ルールの更新
- Azure BoardsのGitHub Enterpriseサポート
- 作業項目のコメントを編集もしくは削除する
- 作業項目フォームで状態の値を並び変えた
Azure Pipelines:
- Azure PowerShellのAz moduleサポート
- YAMLパイプラインでコードをチェックアウトするディレクトリを選択する
- プライベートプロジェクトが並列ジョブの実行ごとに上限60分になります
- hostedパイプラインイメージの更新
- Duffle tool installerタスクがビルドとリリースパイプラインで使えるようになりました
- SlackからAzure Pipelinesの展開を承認する
- すべてのソースプロバイダーが新しいビルドパイプラインウィザーでサポートされるようになりました
- GitHubコミットトリガーの最適化
- CTestとPHPUnitテスト結果の発行
Azure Artifacts:
Reporting:
Administration:
AB＃{work item ID}シンタックスを使用してGitHubでissueのコメント、pull request、またはcommitの中でワークアイテムに言及すると、それらの言及はハイパーリンクになり、クリックして言及したワークアイテムに直接移動できます。
これにより、関連する会話ごとにAzure Boardsの作業項目が乱雑になるような正式なリンクが作成されるのではなく、コードや顧客から報告された問題について議論しながら作業項目に関する情報をもう少し提供できます。詳細については、Azure Boards GitHub integrationを参照してください。
さまざまなプロセスや作業項目の種類で矛盾している複数の作業項目の移行規則を整理しました。Closed By、 Closed Date、State Changed Dateなどの、すべての標準作業項目タイプと新しくカスタマイズされた継承作業項目タイプで修正されました。 Activated ByおよびActivated Dateは、すべてのシステム作業項目の種類で固定されていますが、カスタマイズされた継承作業項目の種類では固定されません。
チームのAzure BoardsプロジェクトをGitHub Enterprise Serverインスタンスでホストされているリポジトリへ接続できるようになりました。OAuthを使用して接続する場合、リポジトリへの接続を作成する前にRegistering an OAuth applicationというドキュメントの手順にしたがってください。
Developer Communityフォーラムで大きく賛成票を集めた機能として、Azure Boardsでの作業項目のディスカッションにおいて、コメントを編集および削除できるようになったことをお知らせします。あなたのコメントを編集するには、シンプルにあなたが所有する任意のコメントの上にカーソルを合わせると、2つの新しいボタンが出てきます。鉛筆アイコンをクリックすると、編集モードになるので、編集を行い、「更新」ボタンを押すだけで編集内容を保存できます。
オーバーフローメニューをクリックすると、コメントを削除するオプションが表示されます。これをクリックすると、このコメントを削除してもいいか確認するために再度プロンプトが表示されたあと、コメントが削除されます。
作業項目フォームのhistoryタブに、編集および削除されたすべてのコメントの完全な監査証跡があります。また、ディスカッションエクスペリエンスのUIがよりモダンでインタラクティブになるように更新しました。さらに、個々のコメントの開始位置と終了位置を明確にするため、コメントの周りに泡の装飾を追加しました。
以前は、作業項目フォームの状態値はアルファベット順に並べられていました。 今回の更新で、プロセス設定のワークフローの順序に合わせて状態値の順序を変更しました。
注意事項
順序の変更は、Web内のフォームとREST APIにのみ影響します。状態値の順序は、Visual Studio 2017やExcelなどのWIT Client OMを使用しているクライアントでは変更されません。
Azure PowerShellには、コマンドラインからAzureリソースを管理するために使用できる一連のコマンドレットが用意されています。2018年12月に、Azure PowerShell Azモジュールが利用可能になり、Azureリソースを管理するためのモジュールになりました。
以前は、Microsoft hostedエージェントでAzure PowerShell Azモジュールのサポートを提供していませんでした。新しいAzure PowerShellタスクバージョン4.*をビルドパイプラインおよびリリースパイプラインで使用すると、すべてのプラットフォームにおいて新しいAzモジュールのサポートが追加されました。Azure PowerShellタスクバージョン3.* は、AzureRMモジュールを引き続きサポートします。ただし、最新のAzureサービスと機能の追従に遅れてしまわないように、できるだけ早くAzure PowerShellタスクバージョン4.* に切り替えることをお勧めします。
Azモジュールには、新しい構文を使用するようにスクリプトを更新しながら既存のスクリプトを使用するのに役立つ互換モードがあります。Azモジュールとの互換性を有効にするには、Enable-AzureRmAliasコマンドを使用します。エイリアスを使用すると、Azモジュールで古いコマンドレット名を使用できます。Azure RMモジュールからAzure PowerShell Azモジュールへの移行の詳細については、こちらを参照してください。
注意事項
プライベートエージェントを使用している場合、エージェントマシンにAzモジュールをインストールする必要があります。
Azure PowerShell Azモジュールの詳細については、こちらのドキュメントを参照してください。
以前は、$(Agent.BuildDirectory)の下のsディレクトリ(訳注:エージェントインストールの_work/数字/sというフォルダーがソースをダウンロードするフォルダー)にリポジトリをチェックアウトしていました。今回の強化で、GitリポジトリがYAMLパイプラインで使用するためにチェックアウトされるディレクトリを選択できます。
チェックアウト時にpathキーワードを使用すると、フォルダー構造を管理できます。 以下はディレクトリを指定するために使用できるYAMLコードの例です。
steps:
- checkout: self
path: my-great-repoこの例では、コードはエージェントのワークスペースのmy-great-repoディレクトリにチェックアウトされます。パスを指定しないと、リポジトリは引き続きsというディレクトリにチェックアウトされます。
これまで、無料アカウント(つまり、パラレルジョブを購入していないアカウント)では、一度に最大30分、月に1,800分までジョブを実行できました。今回のアップデートで、無料アカウントの制限が30分から60分に延長されました。
パイプラインを60分以上実行する必要がある場合は、並列ジョブごとに追加のお金を支払うか、またはself-hostedエージェントで実行できます。self-hostedエージェントには、ジョブ実行時間に関する制限はありません。
hosted Azure Pipelines用に、VS2017、Ubuntu 16.04、およびWindows Container 1803 VMイメージが更新されました。最新のリリースの詳細については、こちらを参照してください。 私たちのイメージで利用可能なツールの詳細については、GitHubのImage Generationレポジトリをご覧ください。
さらに、コンテナーランタイムとしてMobyを採用しました。Mobyは、コンポーネントをカスタムコンテーナベースのシステムを組み立てるためにDockerによって作成されたオープンフレームワークです。これにより、頻繁にアップストリームのパッチを適用し、コンテナーランタイムを改善できます。
Duffleは、Cloud Native Application Bundles(CNAB)をインストールおよび管理するためのコマンドラインツールです。CNABを使用すると、コンテナー固有のアプリとそのサービスをバンドル、インストール、および管理ができます。
今回の更新では、Duffleバイナリの特定のバージョンをインストールできるようにするパイプラインのビルドとリリースのための新しいタスクを追加しました。
これまで、Slackユーザーがチャンネル内からリリース展開を管理する機能は限られていました。Slack用のAzure Pipelinesアプリを使用すると、チャンネルからのリリース展開を承認または却下できます。Azure Pipelinesポータルに移動する必要がないため、承認プロセスが簡単になります。さらに、Slackモバイルアプリを使用して、外出先でも展開を承認できます。
Azure PipelinesとSlackの連携に関する詳細なドキュメントはこちらをみてください。
これまで、GitHub、Azure Repos、Bitbucket Cloudなどのソースプロバイダーは、従来のパイプラインエディターと新しいパイプラインウィザードの間に分割がありました。今回の更新では、これらすべてを新しいパイプラインウィザードに単一の出発点とできるようにしました。引き続き、ページの下部にあるリンクをクリックして、クラシックエディターを使えばYAMLなしでパイプラインを作成できます。
GitHubのプルリクエストコメントを使用してビルドをトリガーするチームのエクスペリエンスが向上しました。通常、セキュリティのために、これらのチームはプルリクエストを自動的に構築したくはありません。代わりに、チームメンバーにプルリクエストを確認してもらい、安全と判断されたら、pull requestにコメントを付けてビルドを開始します。 新しい設定ではこのオプションが維持されていますが、それでも自動プルリクエストはチームメンバーに対してのみ構築されます。
今回の更新で、私たちはパイプラインでのCTestの実行からテスト結果の発行をサポートしました。CTest結果を公開するには、Publish test resultsタブのTest result format入力でCTestオプションを選択します。
さらに、PHPUnitテスト実行用の発行もサポートしています。JUnitの結果フォーマットは常にサポートされていますが、現在はPHPUnitの特定の構成要素を利用できます。テスト結果の公開に関する詳細はこちらのドキュメントを参照してください。
Mavenフィードにupstreamソースが利用可能になりました。これには、Maven CentralのプライマリリポジトリとAzure Artifactsフィードが含まれます。Maven upstreamを既存のフィードに追加するには、Feed Settingsにアクセスし、Upstream sources pivotを選択してからAdd upstream sourceを選択します。
Azure DevOpsのAnalyticsサービスは、ODataを使用してサポートされているブラウザから直接クエリできるエンティティセットで構成されています。このサービスは、_odata要素に追加できるバージョン付きOData APIを提供します。
今回の更新では、テストエンティティセットをバージョン3.0プレビューに移行しています。OData 2.0プレビューバージョンのエンドポイントを使用している場合、3.0-previewでの非互換を伴う更新を防ぐためには、バージョンを指定する必要があります。
次のリストには、バージョン3.0-previewに移行される予定のエンティティセットが含まれています。
- TestRuns
- TestResults
- Tests
- Builds
- Branches
- Releases
- ReleaseEnvironments
- TestResultsDaily
- ReleasePipelines
- ReleaseStages
- BuildPipelines
AnalyticsとODataエンドポイントを使う場合の詳細な情報は、こちらのAnalyticsサービスのドキュメントを読んでください。
Sprint 148のアップデートで、Azure DevOpsポータル内から組織をAzure Active Directoryへ接続できるようになりました。この新しく簡素化されたエクスペリエンスにより、これまでAzureポータルで必要とされていたいくつかの手順を省くことができました。ただし、接続プロセス中にアクセスを失ったメンバーのアクセスを回復するには、まだサポートに電話をかけなければならなかったため、この新しいエクスペリエンスには大きなギャップがありました。新しく接続されたAzure Active Directoryに以前のログインIDが見つからないと、ユーザーはアクセスを失います。今回のリリースでは、切断されたメンバーを自分で復元できるようになり、カスタマーサポートへの問い合わせが不要になり、生産性が向上します。
切断されたメンバーを復元するには2つのステップがあります。まず、これらのメンバーの現在のIDが、新しく接続されたAzure ADのIDにマッピングされます。一部の切断されたメンバーはAzure AD内で一致するIDを持っていない可能性があるため、2番目のステップは、残りのメンバーをAzure ADへのゲストとして招待することです。この更新プログラムは、Azure DevOpsポータルのAzure AD設定ページから両方の手順を実行するためのインターフェイスを提供します。
こちらのドキュメントで最新版を探してください。
これらの機能についてどう思っているかお聞きしたいと思います。 フィードバックメニューを使用して問題を報告するか、提案を提出してください。
アドバイスや回答を必要とする質問がある場合、Stack Overflowコミュニティで聞いてください。
ありがとうございました。
Chris Patterson