Edit

Configure Deployment Strategies from Azure portal

  • Article

With this sprint, we are enabling users to choose their deployment strategies directly from within the Azure portal, and we are rolling out several improvements to the Pipelines and Repos user experience.

Features

General

Azure Repos

Azure Pipelines

General

Azure DevOps now allows team admins to subscribe to events from MS Teams & Slack

In addition to Project administrators, Azure DevOps now allows Team admins to subscribe to events for Azure Boards, Azure Repos, and Azure Pipelines directly from Slack and MS Teams.

MS Teams & Slack notifications for Repos events

As enhancement to our MS Teams and Slack integration you now can choose to subscribe to one or more events on a pull request such as comments, code push, updates, and merge attempts.

Notifications for Repos events.

Azure Repos

Add attachments while creating a pull request

You can now add an attachment to a pull request when creating it. To add an attachment, you previously had to create the pull request then edit it, but now you can directly drag and drop an image to the create pull request page. Add attachments while creating a pull request.

New web platform conversion – Repository settings

We have converted the two Repository settings pages to a single experience that was upgraded to a new web platform. This upgrade not only makes the experience faster and more modern, but these pages also provide a single entry-point for all policies from the project level to the branch level.

New web platform conversion.

With this new experience, navigation for projects with a substantial number of repositories has become easier because of faster load times and an added search filter. You can also view project level policies and the list of cross-repo policies under the Policies tab.

View cross-repo policies under the Policies tab.

If you click into a repository, you can view policies and permissions set at the repository level. Within the policies tab, you can view a list of every branch that policy is set on. Now, click on the branch to see the policies all while never leaving the Repository settings page.

Select branch to see the policies.

Now, when policies are inherited from a higher scope than what you are working with, we show you where the policy was inherited from next to each individual policy. You can also navigate to the page where the higher-level policy was set by clicking the scope name.

Show where the policy was inherited from.

The policy page itself has also been upgraded to the new web platform with collapsible sections! To improve the experience of looking for a particular Build Validation, Status Check, or Automatic Reviewer policy, we have added search filters for each section.

Search filters for each section.

Azure Pipelines

Jobs can access output variables from previous stages

Output variables may now be used across stages in a YAML-based pipeline. This helps you pass useful information, such as a go/no-go decision or the ID of a generated output, from one stage to the next. The result (status) of a previous stage and its jobs is also available.

Output variables are still produced by steps inside of jobs. Instead of referring to dependencies.jobName.outputs['stepName.variableName'], stages refer to stageDependencies.stageName.jobName.outputs['stepName.variableName'].

Note

By default, each stage in a pipeline depends on the one just before it in the YAML file. Therefore, each stage can use output variables from the prior stage. You can alter the dependency graph, which will also alter which output variables are available. For instance, if stage 3 needs a variable from stage 1, it will need to declare an explicit dependency on stage 1.

Limit build service repos scope access

Building upon improving pipeline security by restricting the scope of access tokens Azure Pipelines can now scope down its repository access to just the repos required for a YAML-based pipeline. This means that if the pipelines's access token were to leak, it would only be able to see the repo(s) used in the pipeline. Previously, the access token was good for any Azure Repos repository in the project, or potentially the entire collection.

This feature will be on by default for new projects and organizations. For existing organizations, you must enable it in Organization Settings > Pipelines > Settings. When using this feature, all Azure Repos Git repositories accessed by the pipeline using the build service identity must be explicitly checked out using a checkout step in the job that uses the repository. For more information, see Limit job authorization scope to referenced Azure DevOps repositories.

Getting details at runtime about multiple repositories

When a pipeline is running, Azure Pipelines adds information about the repo, branch, and commit that triggered the run. Now that YAML pipelines support checking out multiple repositories, you may also want to know the repo, branch, and commit that were checked out for other repositories. This data is available via a runtime expression, which now you can map into a variable. For example:

resources:
  repositories:
  - repository: other
    type: git
    name: MyProject/OtherTools
variables:
  tools.ref: $[ resources.repositories['other'].ref ]

steps:
- checkout: self
- checkout: other
- bash: echo "Tools version: $TOOLS_REF"

Multi stage pipelines GA

Multi-stage pipelines UI is now generally available. The corresponding preview feature toggle has been removed. 

You can navigate to the new experience by selecting Pipelines -> Pipelines under the left navigation menu in Azure DevOps. This experience is the entry point for both classic build pipelines as well as YAML pipelines. It is mobile-friendly and brings various improvements to how you manage your pipelines. You can drill down and view pipeline details, run details, pipeline analytics, job details, logs, and more.

To learn more about the multi-stage pipelines user experience, see the documentation here.

Multi stage pipelines.

Configure Deployment Strategies from Azure portal

With this capability, we have made it easier for you to configure pipelines that use the deployment strategy of your choice, for example, Rolling, Canary, or Blue-Green. Using these out-of-box strategies, you can roll out updates in a safe manner and mitigate associated deployment risks. To access this, click on the 'Continuous Delivery' setting in an Azure Virtual Machine. In the configuration pane, you will be prompted to select details about the Azure DevOps project where the pipeline will be created, the deployment group, build pipeline that publishes the package to be deployed and the deployment strategy of your choice. Going ahead will configure a fully functional pipeline that deploys the selected package to this Virtual Machine.

For more details, check out our documentation on configuring Deployment Strategies.

Configure Deployment Strategies from Azure portal.

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.