次の方法で共有

作業項目の状態遷移を制限する

  • [アーティクル]

プレビュー段階のいくつかのスプリントの後、スプリント 172 更新プログラムの一部として、すべての顧客に状態遷移制限ルールの一般リリースが発表されます。

詳細については、以下の Features 一覧を参照してください。

機能

Azure Boards

Azure Pipelines

Azure Artifacts

Azure Boards

状態遷移の制限規則

プライベート プレビューのいくつかのスプリントの後、すべての顧客に対して状態遷移制限ルールが一般提供されるようになりました。 この新しい作業項目の種類ルールを使用すると、作業項目をある状態から別の状態に移動することを制限できます。 たとえば、バグを [新規] から [解決済み] に制限できます。 代わりに、新しい -> アクティブ -> 解決済みから移動する必要があります

この例では、[新規] 状態から [解決済み] 状態に移動するのではなく、[新しい] 状態から [解決済み] に移動するようにバグを制限します。

また、グループ メンバーシップ別に状態遷移を制限するルールを作成することもできます。 たとえば、[承認者] グループ内のユーザーのみが、New -> Approved からユーザー ストーリーを移動できます。

作業項目をコピーして子をコピーする

Azure Boards で要求される上位の機能の 1 つは、子作業項目もコピーする作業項目をコピーする機能です。 このスプリントでは、作業項目のコピー ダイアログに "子作業項目を含める" という新しいオプションを追加しました。 このオプションを選択すると、作業項目がコピーされ、すべての子作業項目 (最大 100 個) がコピーされます。

このページには、コピーした作業項目に子作業項目を含める Azure Boards の新しいオプションが表示されます。

アクティブ化されたフィールドと解決されたフィールドのルールが改善されました

これまで、 Activated By、 Activated Date、 Resolved By、 Resolved Date のルールは謎でした。 これらはシステム作業項目の種類にのみ設定され、"Active" と "Resolved" の状態値に固有です。 スプリント 172 では、これらのルールが特定の状態でなくなったようにロジックを変更しました。 代わりに、状態が存在するカテゴリ (状態カテゴリ) によってトリガーされます。 たとえば、解決済みカテゴリのカスタム状態が "テストが必要" であるとします。 作業項目が "アクティブ" から "テストが必要" に変わると、 Resolved By ルールと Resolved Date ルールがトリガーされます。

これにより、ユーザーはカスタム状態値を作成し、カスタム ルールを使用しなくても、 Activated By、 Activated Date、 Resolved By、 Resolved Date フィールドを生成できます。

バックログとボード上のシステム作業項目の種類 (プライベート プレビュー)

継承プロセス モデルの開始以来、いくつかの作業項目の種類がボードとバックログに追加されないように除外されています。 これらの作業項目の種類は次のとおりです。

プロセス 作業項目の種類
アジャイル 問題点
スクラム 障害
CMMI 変更要求
問題点
確認
リスク

このスプリントを開始すると、これらの作業項目の種類を任意のバックログ レベルで使用できるようにする必要があるお客様向けのプライベート プレビューが可能になります。

この Azure Boards ページを使用して、以前に除外した作業項目の種類をボードとバックログに追加します。

この機能のプレビューに関心がある場合は、組織名をメールでお問い合わせください。

Azure Pipelines

排他展開ロック ポリシー

この更新プログラムを使用すると、一度に 1 回の実行のみが環境にデプロイされるようにすることができます。 環境で [排他ロック] チェックを選択すると、1 回の実行のみが続行されます。 その環境にデプロイする後続の実行は一時停止されます。 排他ロックを使用した実行が完了すると、最新の実行が続行されます。 中間実行はすべて取り消されます。

[チェックの追加] ページで、[排他ロック] を選択して、一度に 1 回の実行のみが環境にデプロイされるようにします。

パイプライン リソース トリガーのステージ フィルター

このスプリントでは、YAML のパイプライン リソースのフィルターとして "ステージ" のサポートを追加しました。 このフィルターを使用すると、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. 
      - Production

トリガー フィルターで指定されたステージが CI パイプラインで正常に完了すると、CD パイプラインに対して新しい実行が自動的にトリガーされます。

YAML パイプライン用の汎用 Webhook ベースのトリガー

現在、成果物を使用して自動トリガーを有効にできるさまざまなリソース (パイプライン、コンテナー、ビルド、パッケージなど) があります。 ただし、これまでは、他の外部イベントやサービスに基づいてデプロイ プロセスを自動化できませんでした。 このリリースでは、任意の外部サービスとのパイプライン自動化の統合を可能にするために、YAML パイプラインで Webhook トリガーのサポートを導入します。 Webhook (GitHub、GitHub Enterprise、Nexus、Artifactory など) を使用して外部イベントをサブスクライブし、パイプラインをトリガーできます。

Webhook トリガーを構成する手順を次に示します。

  1. 外部サービスで Webhook をセットアップします。 Webhook を作成するときは、次の情報を指定する必要があります。

    • 要求 URL - "https://dev.azure.com/<ADO Organization>/_apis/public/distributedtask/webhooks/<WebHook Name>?api-version=6.0-preview"
    • シークレット - これは省略可能です。 JSON ペイロードをセキュリティで保護する必要がある場合は、 Secret 値を指定します

  2. 新しい "着信 Webhook" サービス接続を作成します。 これは、次の 3 つの重要な情報を定義できる、新しく導入されたサービス接続の種類です。

    • Webhook 名: Webhook の名前は、外部サービスで作成した Webhook と一致する必要があります。
    • HTTP ヘッダー - 要求検証用のペイロード ハッシュ値を含む要求内の HTTP ヘッダーの名前。 たとえば、GitHub の場合、要求ヘッダーは "X-Hub-Signature" になります。
    • シークレット - シークレットは、受信要求の検証に使用されるペイロード ハッシュを解析するために使用されます (これは省略可能です)。 Webhook の作成にシークレットを使用した場合は、同じ秘密鍵を指定する必要があります

    [サービス接続の編集] ページで、Webhook トリガーを構成します。

  3. webhooks という新しいリソースの種類が YAML パイプラインに導入されています。 webhook イベントをサブスクライブするには、パイプラインで Webhook リソースを定義し、それを受信 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'
    ### JSON payload data is available in the form of ${{ parameters.<WebhookAlias>.<JSONPath>}}
    script: |
      Write-Host ${{ parameters.MyWebhookTrigger.repositoryName}}
      Write-Host ${{ parameters.MyWebhookTrigger.component.group}}
  1. 受信 Webhook サービス接続によって Webhook イベントが受信されるたびに、webhook イベントにサブスクライブされているすべてのパイプラインに対して新しい実行がトリガーされます。

YAML リソース トリガーの問題のサポートと追跡可能性

パイプライン トリガーが期待どおりに実行できない場合は、混乱を招く可能性があります。 これを理解しやすくするために、"トリガーの問題" という名前の新しいメニュー項目をパイプライン定義ページに追加しました。トリガーが実行されていない理由に関する情報が表示されます。

リソース トリガーは、2 つの理由で実行に失敗する可能性があります。

  1. 指定されたサービス接続のソースが無効な場合、またはトリガーに構文エラーがある場合、トリガーはまったく構成されません。 これらはエラーとして表示されます。

  2. トリガー条件が一致しない場合、トリガーは実行されません。 これが発生するたびに、条件が一致しなかった理由を理解できるように警告が表示されます。

    トリガーの問題と呼ばれるこのパイプライン定義ページには、トリガーが実行されていない理由に関する情報が表示されます。

パイプライン ページに警告バナーが追加され、お使いのリージョンで進行中のインシデントがユーザーに警告され、パイプラインに影響する可能性があります。

Azure Artifacts

UI から組織範囲のフィードを作成する機能

オンプレミスサービスとホステッド サービスの両方について、Web UI を通じて組織スコープのフィードを作成および管理する機能を顧客に提供しています。

[成果物] -> [フィードの作成] に移動し、[スコープ] 内でフィードの種類を選択することで、UI を介して組織スコープのフィードを作成できるようになりました。

[成果物]、[フィードの作成] の順に選択し、[スコープ] 内でフィードの種類を選択して、組織スコープのフィードを作成します。

他の Azure DevOps オファリングに合わせてプロジェクト スコープのフィードを使用することをお勧めしますが、UI やさまざまな REST API を使用して、組織スコープのフィードを再度作成、管理、使用できます。 詳細については、フィードのドキュメントを参照してください。

次のステップ

Note

これらの機能は、今後 2 ~ 3 週間にわたってロールアウトされます。

Azure DevOps に向かい、見てみましょう。

Azure DevOps に移動する

フィードバックの提供方法

これらの機能に関するご意見をお聞かせください。 ヘルプ メニューを使用して、問題を報告したり、提案を提供したりします。

ご提案の送信

Stack Overflow のコミュニティからアドバイスや質問に回答してもらうこともできます。

よろしくお願いします。

アーロン・ハルベルク