プレビューでの数回のスプリントを経て、このたび、スプリント172アップデートの一環として、すべてのお客様にstate transition restriction rulesを一般提供開始することを発表します。
詳細は以下の新機能一覧をご覧ください。
- 状態遷移を制限するルールを提供します
- 子供を含めて作業項目のコピーができるようになります
- ActivatedとResolvedフィールドに対するルールが改良されました
- backlogとboardsにシステム定義の作業項目が設定できるようになりました（プライベートプレビュー）
- デプロイ時に排他制御するためためのロックポリシーが設定できるようになりました
- パイプラインのresource内のtriggersにStagesフィルターが設定できるようになりました
- YAMLパイプラインでGeneric webhookトリガーが設定可能になりました
- YAMLパイプラインのtriggerリソースの問題解決のサポートと透明化を提供します
- 本番サイトでインシデントが発生してパイプラインへの影響をバナーで表示するようにしました
プライベートプレビューの数回のスプリントの後、状態遷移制限ルールをすべてのお客様に一般提供開始しました。この新しい作業項目タイプのルールでは、作業項目をある状態から別の状態に移動させないように制限できます。たとえば、バグをNewからResolvedに移行させないように制限できます。制限した場合、New→Active→Resolvedの順に移動しなければなりません。
また、グループのメンバーシップによって状態遷移を制限するルールの作成も可能です。たとえば、“Approvers”グループのユーザーのみが、ユーザーストーリーをNew→Approvedへ移動可能に設定できます。
Azure Boardsでもっとも要望の多かった機能のひとつは、子作業項目も含めてコピーする機能です。今回のスプリントでは、作業項目のコピーダイアログに"Include child work items"という新しいオプションを追加しました。このオプションを選択すると、作業項目がコピーされ、すべての子作業項目がコピーされます（100個まで可能です）。
これまで、Activated By、Activated Date、Resolved By、Resolved Dateのルールは謎に包まれていました。これらのルールは、システムの作業項目タイプに対してのみ設定され、"Active"と"Resolved"の状態値に固有のものでした。Sprint 172では、これらのルールは特定の状態を対象としないようにロジックを変更しました。代わりに、状態が存在するカテゴリ（状態カテゴリ）によってトリガーされます。たとえば、"Resolved"カテゴリに"Needs Testing"というカスタム状態があるとします。作業項目が「Active」から「Needs Testing」に変更されると、Resolved ByとResolved Dateのルールがトリガーされます。
これにより、みなさんは任意のカスタム状態値を作成しても、カスタム・ルールを使用しなくても、Activated By、Activated Date、Resolved By、Resolved Dateフィールドを生成できます。
継承プロセスモデルの開始以来、いくつかの作業項目の種類がボードやバックログへ追加されないようになっています。これらの作業項目の種類には以下のものが含まれます。
| Process | Work Item Type |
|---|---|
| Agile | Issue |
| Scrum | Impediment |
| CMMI | Change Request |
| Issue | |
| Review | |
| Risk |
このスプリントから、これらの作業項目タイプをどのバックログレベルでも利用できるようにしたいと考えているお客様のために、プライベートプレビューを開始しています。
このプレビュー機能をためしたい場合、組織名をメールでお知らせいただければ、機能を有効にします。
今回のアップデートでは、一度にひとつの環境にひとつのデプロイの実行のみを確実に展開できるようになりました。環境の "Exclusive lock"をチェックを選択することで、1回の実行のみが実行されます。その環境へのデプロイを希望するそれ以降のデプロイの実行は一時停止されます。排他的ロックのある実行が完了すると、最新のデプロイが実行されます。中間の展開はすべてキャンセルされます。
このスプリントでは、YAMLのパイプラインリソースのフィルターに'stages'のサポートを追加しました。このフィルターを使うと、CDパイプラインをトリガーするためにCIパイプライン全体が完了するのを待つ必要はありません。CIパイプラインの特定のステージが完了したときにCDパイプラインの実行が可能となります。
resources:
pipelines:
- pipeline: MyCIAlias
project: Fabrikam
source: Farbrikam-CI
trigger:
stages: ### This stage filter is used when evaluating conditions for triggering your CD pipeline
- PreProduction ### stages are AND'ed. On successful completion of all the stages provided, your CD pipeline will be triggered.
- Productiontriggerフィルターで提供されたステージがCIパイプラインで正常に完了すると、CDパイプラインの新しい実行が自動的に起動されます。
今日では、さまざまなリソース（パイプライン、コンテナー、ビルド、パッケージなど）を利用して、成果物を消費し、自動トリガーを有効にできます。しかし、今までは、他の外部イベントやサービスに基づいてデプロイプロセスの自動化は不可能でした。このリリースでは、任意の外部サービスを組み合わせてパイプライン自動化の統合を可能にするため、YAMLパイプラインにwebhookトリガーのサポートを導入しています。そのウェブフック（GitHub、GitHub Enterprise、Nexus、Aritfactoryなど）を介して任意の外部イベントをサブスクライブし、パイプラインの実行が可能になります。
ここでは、ウェブフックのトリガーを設定する手順を説明します。
- 外部サービスにwebhookを設定します。Webhook を作成する際には、以下の情報を指定する必要があります。
- Request Url - "https://dev.azure.com/{organization}/_apis/public/distributedtask/webhooks/?api-version=6.0-preview"
- Secret - これはオプションです。JSONペイロードを保護する必要がある場合、Secret値を指定します。
- 新しい"Incoming Webhook"サービス接続を作成します。これは新しく導入されたサービス接続タイプで、3つの重要な情報を定義します。
- Webhook Name: Webhookの名前は、外部サービスで作成したWebhookと一致している必要があります。
- HTTP Header - リクエスト検証用のペイロードハッシュ値を含むリクエストのHTTPヘッダーの名前。たとえば、GitHubの場合、リクエストヘッダーは "X-Hub-Signature"になります。
- Secret - secretは、受信したリクエストの検証に使用するペイロードハッシュを解析するために使用します（これはオプションです）。webhookを作成する際にsecretを使用している場合は、同じsecretキーを提供する必要があります。
- YAMLパイプラインでは
webhooksと呼ばれる新しいリソースタイプが導入されています。webhookイベントを購読するためには、パイプライン内にwebhookリソースを定義し、Incoming webhookサービス接続をポイントする必要があります。また、各パイプラインのトリガーをさらにカスタマイズする場合、JSONペイロードデータに基づいてwebhookリソースに追加のフィルターを定義することができ、ジョブ内で変数の形でペイロードデータを参照できます。
resources:
webhooks:
- webhook: MyWebhookTrigger ### Webhook alias
connection: MyWebhookConnection ### Incoming webhook service connection
filters:
- path: repositoryName ### JSON path in the payload
value: maven-releases ### Expected value in the path provided
- path: action
value: CREATED
steps:
- task: PowerShell@2
inputs:
targetType: 'inline'
script: |
Write-Host ${{ parameters.MyWebhookTrigger.repositoryName}} ### JSON payload data is available in the form of ${{ parameters.<WebhookAlias>.<JSONPath>}}
Write-Host ${{ parameters.MyWebhookTrigger.component.group}}- Incoming Webhookサービス接続でwebhookイベントを受信するたびに、webhookイベントを受信しているすべてのパイプラインに対して新しい実行が行われます。
パイプライントリガーが期待通りに実行されない場合、混乱を招くことがあります。これを理解しやすくするために、パイプライン定義ページに'Trigger Issues'という新しいメニュー項目を追加し、トリガーが実行されない理由に関する情報を表示しました。
リソーストリガーが実行に失敗するのには、ふたつの理由があります。
- 提供されたサービス接続のソースが無効な場合、またはトリガーに構文エラーがある場合、トリガーは設定されません。これらはエラーとして表示されます。
- トリガー条件が一致しない場合、トリガーは実行されません。これが発生するたびに警告が表示されるので、なぜ条件が一致しなかったのかを理解できます。
パイプラインのページに警告バナーを追加し、お客様のパイプラインに影響を与える可能性のある、お客様のOrganizationがあるリージョンで進行中のインシデントについてユーザーに注意を喚起します。
オンプレミスとホステッドの両方のサービスで、Web UIからOrganizationスコープのフィードを作成して管理できる機能を復活させます。
Artifacts → Create Feedと進み、スコープ内でフィードの種類を選択することで、UIを介して組織スコープ付きフィードを作成できるようになりました。
Azure DevOpsオファリングに合わせて、プロジェクト単位で制限されたフィードの使用を推奨していますが、UIとさまざまなREST APIを使い、Organization単位で参照可能なフィードを再度作成、管理、使用できます。詳細については、フィードのドキュメントを参照してください。
注意事項
ここで議論されている機能は今後二～三週にわたって順次展開されます。
これらの新機能を読んだ後、次のリンクからぜひご自身でAzure DevOpsサービスを体験してみてください。
これらの機能についてどう思っているかお聞きしたいと思います。 フィードバックメニューを使用して問題を報告するか、提案を提出してください。
アドバイスや回答を必要とする質問がある場合、Stack Overflowコミュニティで聞いてください。
Aaron Hallberg