今回のアップデートでは、Azure BoardsとGitHubの統合における最新の改善点のプライベートプレビューを提供します!
また、管理者が Azure Pipelines でhotfixを素早く提供するために、承認やチェックの実行をバイパスできるようになりました。
詳細はリリースノートをご覧ください。
- Azure PipelinesのタスクをNode 16ベースへ移行します
- 非推奨タスクの廃止日程を発表します
- AzureRmWebAppDeploymentタスクでMicrosoft Entra ID認証をサポートされます
- 承認用のREST APIを改善しました。承認の発見と対象パイプラインの発見が容易になります
- 必須テンプレートチェックでGitHub Enterprise Serverをサポートしました
- 承認とチェックのバイパスができるようになりました
- Azure Functionでのチェック呼び出しの再実行が可能になりました
今回のアップデートでは、Azure DevOps Web Extension SDKの新バージョンをリリースします。クライアントSDKは、Web拡張機能がホストフレームと通信できるようにします。次のような用途に使用できます。
- 拡張機能がロードされたこと、またはエラーが発生したことをホストに通知する
- 現在のページに関する基本的なコンテキスト情報(現在のユーザー、ホスト、拡張機能情報)の取得
- テーマ情報の取得
- Azure DevOps への REST 呼び出しで使用する認証トークンの取得
- ホストフレームが提供するリモートサービスを取得する
完全なAPIリファレンスは、azure-devops-extension-sdkパッケージのドキュメントにあります。この新しいバージョンでは、以下のモジュールがサポートされます。
-
ESモジュールのサポート: 従来の AMD (非同期モジュール定義) モジュールに加え、ES (ECMAScript) モジュールもサポートするようになりました。ESモジュール構文を使用してSDKをインポートできるようになり、パフォーマンスが向上し、アプリケーションのサイズが小さくなります。
-
AMDモジュールの後方互換性: AMDモジュールの既存のサポートはそのまま残っています。プロジェクトでAMDモジュールを使用している場合、変更することなく従来通り使用できます。
How to use:
ESモジュールを使用するには、importステートメントを使用して我々が提供するモジュールをインポートします。
import * as SDK from 'azure-devops-extension-sdk';
// Use the module here
AMDモジュールを使用している場合、require関数を使用してSDKをインポートし続けることができます。
require(['azure-devops-extension-sdk'], function(SDK) {
// Use the module here
});
Boards + GitHub の統合改善の道のりは、AB# 構文を使って作業項目にリンクする際のボットの反応に対処することから始まります。AB#{ID}
構文を使用して Pull Request にリンクする場合、リンクが成功したかどうかを知る唯一の方法は、作業項目を見るか、AB#{ID}
がリンクに変わったかどうかでしか気づけませんでした。
本日、私たちは Azure Boards GitHub アプリのいくつかの機能強化を特徴とするプライベートプレビューを開始します。これにより、不正なリンクを特定し、Pull Request がマージされる前の修正が可能になります。
プライベートプレビューへの参加に興味がある方は、メールで直接ご連絡ください。必ず組織名(dev.azure.com/{organization})を明記してください。
今後の Azure Boards + GitHub 統合機能の詳細については、公開ロードマップをご覧ください。
パイプライン内のタスクはランナーを使用して実行され、ほとんどの場合Node.jsが使用されます。ランナーとして Node を使用する Azure Pipelines タスクは、現在すべて Node 16 を使用します。Node 16はAppleシリコンをネイティブにサポートする最初のNodeバージョンであるため、Appleシリコン上のmacOSの完全なタスクサポートも提供しています。Apple シリコン上で動作するエージェントにおいて、Rosetta を実行する必要はありません。
しかしながら、Node 16の終了日が前倒しされたため、Node 20でタスクを実行するための作業を開始しました。
Azure Pipelinesには、非推奨タスクが多数あります。非推奨タスクは2024年1月31日に廃止されます。非推奨タスクを使用しているパイプラインを識別しやすくするため、そのようなタスクが使用されている場合、パイプラインに警告が表示されます。タスク・リファレンスを更新し、非推奨のステータスと廃止日を明確に示しました。
以下のタスクが非推奨となり、警告が表示されるようになります。
- AppCenterDistributeV1, AppCenterDistributeV2
- AzureMonitorV0
- ChefKnifeV1
- ChefV1
- CondaEnvironmentV1
- DeployVisualStudioTestAgentV2
- DotNetCoreInstallerV1
- IISWebAppDeployment
- QuickPerfTestV1
- RunJMeterLoadTestV1
- RunLoadTestV1
- SqlServerDacpacDeploymentV1
- XamarinTestCloudV1
2024年1月31日までに、より新しいタスクのバージョンまたは代替手段を使用するようにパイプラインを更新してください。
AzureRmWebAppDeploymentV3および AzureRmWebAppDeployment@4 タスクは、基本認証が無効となっているApp Serviceをサポートを提供します。App Service で基本認証が無効になっている場合、AzureRmWebAppDeploymentV3/4 タスクは Microsoft Entra ID認証を使用して App Service Kudu エンドポイントへのデプロイを実行します。これには、エージェントにインストールされている msdeploy.exe の最新バージョンが必要です。これは、Hosted agentのwindows-2022/windows-latestを使用する場合の話です(タスク リファレンスを参照)。
ユーザーが所属するグループを検索結果に含めることで、ユーザーに割り当てられた承認を見つけやすくなりました。
承認は、所属するパイプラインランに関する情報を含むようになりました。
たとえば、次の GET REST API 呼び出しを行うと以下のJSONが返却されます。
https://dev.azure.com/fabrikam/FabrikamFiber/_apis/pipelines/approvals?api-version=7.2-preview.2&top=1&assignedTo=john@fabrikam.com&state=pending
{
"count": 1,
"value":
[
{
"id": "7e90b9f7-f3f8-4548-a108-8b80c0fa80e7",
"steps":
[],
"status": "pending",
"createdOn": "2023-11-09T10:54:37.977Z",
"lastModifiedOn": "2023-11-09T10:54:37.9775685Z",
"executionOrder": "anyOrder",
"minRequiredApprovers": 1,
"blockedApprovers":
[],
"_links":
{
"self":
{
"href": "https://dev.azure.com/fabrikam/26dcfaeb-d8fe-495c-91cb-fec4acb44fbb/_apis/pipelines/approvals/7e80b987-f3fe-4578-a108-8a80c0fb80e7"
}
},
"pipeline":
{
"owner":
{
"_links":
{
"web":
{
"href": "https://dev.azure.com/buildcanary/26dcfaeb-d8fe-495c-91cb-fec4acb44fbb/_build/results?buildId=73222930"
},
"self":
{
"href": "https://dev.azure.com/buildcanary/26dcfaeb-d8fe-495c-91cb-fec4acb44fbb/_apis/build/Builds/73222930"
}
},
"id": 73222930,
"name": "20231109.1"
},
"id": "4597",
"name": "FabrikamFiber"
}
}
]
}
Approvals and checksは、サービス接続、リポジトリ、エージェントプールなどの重要なリソースへのアクセスを保護する際に役立ちます。一般的なユースケースは、本番環境へのデプロイ時に承認とチェックを使用し、ARMサービス接続を保護することです。
サービス接続に次のチェックを追加したとします。Approval、Business Hours(営業時間)チェック、Invoke Azure Function チェック(異なるリージョン間の遅延を強制する)。
ここで、すぐに修正が必要なホットフィックスのデプロイを行う必要があるとします。パイプラインの実行を開始しても、ほとんどのチェックが完了するまで待たされます。修正の承認やチェックの完了を待つ余裕がない場合の運用が困難になっています。
このスプリントでは、承認とチェックの実行をバイパスできるようにしました。
Approvals、Business Hours、Invoke Azure Function、Invoke REST APIのチェックのバイパスが可能になっています。
承認のバイパス。
Bypass Business Hours チェック。
Azure Functionsの呼び出しチェック。Business Hoursチェックのバイパス。
チェックがバイパスされると、チェックパネルで確認できます。
チェックをバイパスできるのは、チェックが定義されたリソースの管理者である場合のみです。
Templateは、組織内のパイプラインのステージ、ジョブ、ステップを制御できるセキュリティ メカニズムです。
Require template check を使用すると、エージェントプールやサービス接続などの保護されたリソースにアクセスする前に、パイプラインが承認されたテンプレートセットから拡張されていることを強制できます。
このスプリントから、GitHub Enterprise Serverのリポジトリにあるテンプレートを指定できるようになりました。
システムを複数の段階に分けてデプロイするとします。2つ目のステージをデプロイする前に、すでにデプロイされたシステムのsanity check(訳注:システムが正常に動作しているか確認するチェックのこと)を実行するApprovalとInvoke Azure Functionチェックがあります。
Approvalリクエストを確認すると、sanity checkが2日前に実行されていることに気づいたとします。このシナリオでは、sanity checkの結果に影響を与えた別のデプロイメントを認識している可能性があります。
今回の更新により、Invoke Azure Function および Invoke REST API チェックを再実行できます。この機能は、チェックが成功し、再試行がない場合にのみ使用できます。
注意事項
チェックを再実行できるのは、チェックが定義されたリソースの管理者である場合のみです。
作業項目チャートのフィルタリングが可能になったことを発表いたします。この機能により、作業項目チャートにカーソルを合わせると概要が表示され、特定のチャートセグメントにドリルダウンすると詳細が表示されます。もう必要なデータにアクセスするためにカスタムクエリを作成する必要はありません。作業項目チャートの作業項目に数クリックでアクセスできるようになりました。
皆様からのフィードバックは、この機能の将来を形作る上で非常に貴重です。今すぐお試しいただき、Azure DevOpsコミュニティでご意見をお聞かせください。
注意事項
ここで議論されている機能は今後二~三週にわたって順次展開されます。
Azure DevOpsサービスを体験してみてください。
これらの機能についてどう思っているかお聞きしたいと思います。 フィードバックメニューを使用して問題を報告するか、提案を提出してください。
アドバイスや回答を必要とする質問がある場合、Stack Overflowコミュニティで聞いてください。
ありがとうございました。
Silviu Andrica