Edit

Restrict work item state transitions

  • Article

After several sprints in preview, we are now announcing the general release of state transition restriction rules to all customers as part of the Sprint 172 Update.

Check out the Features list below for more information.

Features

Azure Boards

Azure Pipelines

Azure Artifacts

Azure Boards

State transition restriction rules

After several sprints of private preview, state transition restriction rules are now generally available for all customers. This new work item type rule allows you to restrict work items from being moved from one state to another. For example, you can restrict Bugs from going from New to Resolved. Instead, they must go from New –> Active -> Resolved

This example restricts Bugs to go from the New state to Active, then to Resolved instead of going from the New to Resolved state.

You can also create a rule to restrict state transitions by group membership. For example, only users in the “Approvers” group can move user stories from New -> Approved.

Copy work item to copy children

One of the top requested features for Azure Boards is the ability to copy a work item that also copies the child work items. In this sprint, we added a new option to "Include child work items" to the copy work item dialog. When selected, this option will copy the work item and copy all child work items (up to 100).

This page shows the new option in Azure Boards to Include child work items in a copied work item.

Improved rules for activated and resolved fields

Up until now, the rules for Activated By, Activated Date, Resolved By, and Resolved Date have been a mystery. They are only set for system work item types and are specific to the state value of "Active" and "Resolved". In sprint 172 we changed the logic so that these rules are no longer for a specific state. Instead, they are triggered by the category (state category) that the state resides in. For example, let's say you have a custom state of "Needs Testing" in the Resolved category. When the work item changes from "Active" to "Needs Testing", the Resolved By and Resolved Date rules are triggered.

This allows customers to create any custom state values and still generate the Activated By, Activated Date, Resolved By, and Resolved Date fields, without the need to use custom rules.

System work item types on backlogs and boards (private preview)

Since the inception of the inheritance process model, several work item types have been excluded from being added to boards and backlogs. These work item types include:

Process Work Item Type
Agile Issue
Scrum Impediment
CMMI Change Request
Issue
Review
Risk

Starting this sprint, we are allowing a private preview for those customers who want to enable these work items types to be available on any backlog level.

Use this Azure Boards page to add previously excluded work item types to boards and backlogs.

If you are interested in previewing this feature, please email us with your organization name and we can give you access.

Azure Pipelines

Exclusive deployment lock policy

With this update, you can ensure that only a single run deploys to an environment at a time. By choosing the "Exclusive lock" check on an environment, only one run will proceed. Subsequent runs which want to deploy to that environment will be paused. Once the run with the exclusive lock completes, the latest run will proceed. Any intermediate runs will be canceled.

In the Add check page, select Exclusive Lock to ensure that only a single run deploys to an environment at a time.

Stages filters for pipeline resource triggers

In this sprint, we added support for 'stages' as a filter for pipeline resources in YAML. With this filter, you don't need to wait for the entire CI pipeline to be completed to trigger your CD pipeline. You can now choose to trigger your CD pipeline upon completion of a specific stage in your CI pipeline.

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

When the stages provided in the trigger filter are successfully completed in your CI pipeline, a new run is automatically triggered for your CD pipeline.

Generic webhook based triggers for YAML pipelines

Today, we have various resources (such as pipelines, containers, build, and packages) through which you can consume artifacts and enable automated triggers. Until now, however, you could not automate your deployment process based on other external events or services. In this release, we are introducing webhook trigger support in YAML pipelines to enable integration of pipeline automation with any external service. You can subscribe to any external events through its webhooks (GitHub, GitHub Enterprise, Nexus, Aritfactory, etc.) and trigger your pipelines.

Here are the steps to configure the webhook triggers:

  1. Setup a webhook on your external service. When creating your webhook, you need to provide the following info:

    • Request Url - "https://dev.azure.com/<ADO Organization>/_apis/public/distributedtask/webhooks/<WebHook Name>?api-version=6.0-preview"
    • Secret - This is optional. If you need to secure your JSON payload, provide the Secret value

  2. Create a new "Incoming Webhook" service connection. This is a newly introduced Service Connection Type that will allow you to define three important pieces of information:

    • Webhook Name: The name of the webhook should match webhook created in your external service.
    • HTTP Header - The name of the HTTP header in the request that contains the payload hash value for request verification. For example, in the case of the GitHub, the request header will be "X-Hub-Signature"
    • Secret - The secret is used to parse the payload hash used for verification of the incoming request (this is optional). If you have used a secret in creating your webhook, you will need to provide the same secret key

    In the Edit service connection page, configure webhook triggers.

  3. A new resource type called webhooks is introduced in YAML pipelines. For subscribing to a webhook event, you need to define a webhook resource in your pipeline and point it to the Incoming webhook service connection. You can also define additional filters on the webhook resource based on the JSON payload data to further customize the triggers for each pipeline, and you can consume the payload data in the form of variables in your jobs.

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. Whenever a webhook event is received by the Incoming Webhook service connection, a new run will be triggered for all the pipelines subscribed to the webhook event.

YAML resource trigger issues support and traceability

It can be confusing when pipeline triggers fail to execute as you expect them to. To help better understand this, we've added a new menu item in the pipeline definition page called 'Trigger Issues' where information is surfaced regarding why triggers are not executing.

Resource triggers can fail to execute for two reasons.

  1. If the source of the service connection provided is invalid, or if there are any syntax errors in the trigger, the trigger will not be configured at all. These are surfaced as errors.

  2. If trigger conditions are not matched, the trigger will not execute. Whenever this occurs, a warning will be surfaced so you can understand why the conditions were not matched.

    This pipeline definition page called Trigger Issues displays information regarding why triggers are not running.

We've added a warning banner to the pipelines page to alert users of ongoing incidents in your region, which may impact your pipelines.

Azure Artifacts

Ability to create org-scoped feeds from UI

We are bringing back the ability for customers to create and manage organization-scoped feeds through the web UI for both on-prem and hosted services.

You can now create org-scoped feeds via the UI, by going to Artifacts -> Create Feed and choosing a type of feed within Scope.

Create organization-scoped feeds by selecting Artifacts, then Create Feed, and selecting a type of feed within Scope.

While we do recommend the usage of project-scoped feeds in alignment with the rest of Azure DevOps offerings, you can again create, manage, and use organization-scoped feeds via UI and various REST APIs. Please see our feeds documentation for more information.

Next steps

Note

These features will roll out over the next two to three weeks.

Head over to Azure DevOps and take a look.

Go to Azure DevOps

How to provide feedback

We would love to hear what you think about these features. Use the help menu to report a problem or provide a suggestion.

Make a suggestion

You can also get advice and your questions answered by the community on Stack Overflow.

Thanks,

Aaron Hallberg