今回の更新では、クラシックビルドパイプラインにおける Azure Pipelines REST API のセキュリティを改善しました。ビルドジョブの認証スコープが、Project Collectionではなく、デフォルトでProjectになりました。
詳しくは、リリースノートをご覧ください。
- Pipelines REST APIのセキュリティを改善しました
- GitHub Enterpriseと併用する際、Proxy URLの構成が可能になりました
- スケジュールビルドが壊れてしまう問題を改善しました
- サービスフックイベント"Run stage state changed"に付加する情報を増やしました
- クラシックビルドパイプラインでの既定のアクセストークンのスコープを変更しました
- Azure Pipelines が ServiceNow の San Diego バージョンをサポートします
- Windows 2016 イメージを廃止します
- macOS 10.15 Catalinaイメージが非推奨となります
Azure Pipelines は、すでに ServiceNow と統合が可能になっています。この統合は、ServiceNow のアプリと Azure DevOps の拡張機能に依存しています。現在、ServiceNowのSan Diego バージョンで動作するようにアプリを更新しています。この統合が動作するようにするには、ServiceNowストアからアプリの新しいバージョン (4.205.2) にアップグレードしてください。
詳細については、ServiceNow Change Managementとの統合のドキュメントを参照してください。
Azure DevOps の REST API の大半は、スコープ付き PAT トークンを使用します。しかし、それらのいくつかは、フルスコープの PAT トークンを必要とします。言い換えれば、これらの API の一部を使用するには、'Full access' を選択してPATトークンを作成する必要があります。このようなトークンは任意の REST API を呼び出すために使用できるため、セキュリティ上のリスクがあります。私たちは、フルスコープのトークンの必要性を取り除くため、各REST APIを特定のスコープに制限できるように、Azure DevOps 全体で改善を行ってきました。この取り組みの一環として、現在リソースごとにパイプラインのREST APIにおける権限を整理し、特定のスコープのみ使用します。スコープは、使用を許可されるリソースの種類に依存します。
Code (read, write, and manage)はrepositoryタイプのリソースに対して使用されます。Agent Pools (read, manage)及びEnvironment (read, manage)はqueueとエージェントプールタイプのリソースに対して使用されます。Secure Files (read, create, and manage)はsecurefileに対して使用されます。Variable Groups (read, create and manage)はvariablegroupタイプのリソースに対して使用されます。Service Endpoints (read, query and manage)はendpointタイプのリソースに対して使用されます。Environment (read, manage)はenvironmentタイプのリソースに対して使用されます。
パイプラインのパーミッションを一括編集するには、やはりフルスコープのPATトークンが必要です。リソースのPipelineパーミッションの更新について詳しくは、Pipeline Permissions - Update Pipeline Permissions For Resourcesというドキュメントを参照してください。
Azure Pipelinesは、オンプレミスの GitHub Enterprise Server と連携し、継続的インテグレーションや PR ビルドを実行します。GitHub Enterprise Server がファイアウォールの内側にあり、プロキシサーバーを介してトラフィックをルーティングする必要があるケースもあります。このシナリオをサポートするために、Azure DevOps の GitHub Enterprise Server サービス接続では、Proxy URL の構成が可能になりました。以前は、Azure DevOps からのすべてのトラフィックがこのProxy URL を介してルーティングされるわけではありませんでした。今回の更新で、Azure Pipelines からの次のトラフィックがProxy URL を経由するようにルーティングされるようになりました。
- Get branches
- Get pull request information
- Report build status
パイプラインのスケジュール情報が破損し、パイプラインがロードされなくなる不具合を修正しました。これは、ブランチ名が一定の文字数を超えた場合などに発生していました。
Azure Pipelinesは、7月31日に Windows 2016 イメージ（vs2017-win2016）を弊社のホスティングプールから削除しています。Windows 2016 を含む非推奨のイメージを使用するパイプラインを特定する方法については、ブログポストHosted Pipelines Image Deprecationをご覧ください。
Azure Pipelines は、弊社のホストプール上の macOS 10.15 Catalina イメージ (macOS-1015) を非推奨としています。このイメージは9月30日にリタイアする予定です。キューにかかる時間が長くなる可能性があります。
どのパイプラインが macOS-1015 イメージを使用しているかをよりよく識別するために、ブラウンアウト（訳注：停電。わざとホストプールを無効にして失敗させること）を計画しています。ブラウンアウト期間中はジョブが失敗します。
- macOS-1015 イメージを使用したパイプラインの実行時に警告メッセージが表示されます。
- macOS-1015 を含む非推奨のイメージを使用したパイプラインを検索するためのスクリプトが利用可能です
- 短時間の「ブラウンアウト」を予定しています。macOS-1015 の実行は、ブラウンアウト期間中に失敗します。そのため、ブラウンアウト前にパイプラインを移行することをお勧めします。
- August 1, 12:00 UTC - August 1, 14:00 UTC
- August 9, 16:00 UTC - August 9, 18:00 UTC
- August 17, 14:00 UTC - August 17, 18:00 UTC
- August 25, 14:00 UTC - August 25, 20:00 UTC
- September 2, 12:00 UTC - September 2, 22:00 UTC
- September 8, 00:00 UTC - September 9, 00:00 UTC
- September 14, 00:00 UTC - September 15, 00:00 UTC
- September 20, 00:00 UTC - September 21, 00:00 UTC
- September 26, 00:00 UTC - September 27, 00:00 UTC
サービスフックを使うと、Azure DevOpsのプロジェクトでイベントが発生したときに、他のサービスでタスクを実行することができ、Run stage state changedはそのイベントの1つです。Run stage state changed イベントには、パイプラインの名前やラン全体の状態など、実行に関する情報を含める必要があります。以前は、実行idと名前に関する情報のみが含まれていました。今回の更新では、不足している情報を含めるために、イベントに変更を加えました。
古典的なビルドパイプラインのセキュリティを向上させるため、新規作成時のbuild job authorization scopeは、デフォルトでProjectになります。今までは Project Collection でした。Job アクセストークンについての詳細はこちらをご覧ください。この変更は、既存のパイプラインには影響しません。この時点から作成する新しいクラシックビルドパイプラインにのみ影響します。
Project Collection Build Service アカウントは、新しい組織スコープの Azure Artifacts フィードが作成されると、現在の Contributor ロールではなく、Collaborator ロールがデフォルトになります。
注意事項
ここで議論されている機能は今後二～三週にわたって順次展開されます。
これらの新機能を読んだ後、次のリンクからぜひご自身でAzure DevOpsサービスを体験してみてください。
これらの機能についてどう思っているかお聞きしたいと思います。 フィードバックメニューを使用して問題を報告するか、提案を提出してください。
アドバイスや回答を必要とする質問がある場合、Stack Overflowコミュニティで聞いてください。
ありがとうございました。
Vijay Machiraju