User assignment based billing, default access level and daily billing - Sprint 158 Update
In the Sprint 158 Update of Azure DevOps, we've added user assignment-based billing. With this feature, the number of Basic or Basic + Test Plan licenses will change as you add or remove users. This means that you will only pay for the licenses that you are using. We’ve also added a new setting that lets you choose whether you want new users added to your organization to get full Basic access or limited/free Stakeholder access.
In addition, we switched from monthly to daily billing. This means that if you give a user paid access for a few weeks or even a few days, you pay only for the time they were assigned the paid access, rather than a full month.
Check out the Features list below for more.
What’s new in Azure DevOps
- User assignment-based billing and default access level
- New UI to manage organization and project permissions
- Support for custom fields in Rollup columns
- New rule to hide fields in a work item form based on condition
- Custom work item notification settings
- Link work items to deployments
- Use service account based authentication to connect to AKS
- Preview Markdown files in pull request Side-by-side diff
- Build policy expiration for manual builds
- Add a policy to block commits based on the commit author email
- Retry failed stages
- Enhancements to approvals in YAML pipelines
- Container structure testing support in Azure Pipeline
- Flaky bug management and resolution
- Enhancements to Azure Pipelines app for Slack and Microsoft Teams
- Updates to hosted pipelines images
- Open Policy Agent installer task
- Pipeline decorators for release pipelines
Azure Test Plans:
User assignment-based billing and default access level
User assignment-based billing
With this update, we've added user assignment-based billing. Instead of having to increase or decrease the number of paid Basic or Basic + Test Plan licenses your organization has available to assign, now that happens automatically when you add or remove users, or change their access level. This means that you’re never paying for more licenses than you’re using, and it makes automating your access level assignment much easier. For example, you have been able to set up group rules to control what access level is assigned to new users that join your team automatically. However, in the past, these only worked if you had extra licenses you were paying for that weren’t assigned to anyone yet, and if you ran out, the group rule failed. Those type of errors no longer happen, as long as the Azure subscription you use for billing stays active.
Default access level for new users
We’ve also added a new setting that lets you choose whether you want new users added to your organization to get full Basic access or limited/free Stakeholder access. In the past, new users got Basic if there were unassigned Basic licenses available, but Stakeholder if there weren’t. All organizations will start with their default access level set to Stakeholder, so there won’t be any unexpected charges for new users. If your organization typically kept extra unassigned licenses, so new users added to projects got full Basic access, make sure to change your default access level to Basic.
As part of the change to assignment-based billing, we've also switched from monthly to daily billing. Now, if you give a user paid access for a few weeks or even a few days, you pay only for the time they were assigned the paid access, rather than a full month. As we switch your organization from monthly to daily billing, your next Azure bill will likely be lower than it has been previously. The next month will be back to normal once it has a full month of accumulated daily charges.
New UI to manage organization and project permissions
Organization and project permissions management have a new look and performance has been improved. Now, new group members will appear in the list as they are added without requiring a forced page refresh. Head over to your Organizations Settings and take a look.
Support for custom fields in Rollup columns
Rollup can now be done on any field, including custom fields. When adding a Rollup column, you can still pick a Rollup column from the Quick list, however if you want to rollup on numeric fields that are not part of the out of the box process template, you can configure your own as follows:
- On your backlog click "Column options". Then in the panel click "Add Rollup column" and Configure custom rollup.
- Pick between Progress Bar and Total.
- Select a work item type or a Backlog level (usually backlogs aggregate several work item types).
- Select the aggregation type. Count of work items or Sum. For Sum you'll need to select the field to summarize.
- The OK button will bring you back to the column options panel where you can reorder your new custom column.
Note that you can't edit your custom column after clicking OK. If you need to make a change, remove the custom column and add another one as desired.
New rule to hide fields in a work item form based on condition
We've added a new rule to the inherited rules engine to let you hide fields in a work item form. This rule will hide fields based on the users group membership. For example, if the user belongs to the "product owner" group, then you can hide a developer specific field. For more details see the documentation here.
Custom work item notification settings
Staying up to date on work items relevant to you or your team is incredibly important. It helps teams collaborate and stay on track with projects and makes sure all the right parties are involved. However, different stakeholders have different levels of investment in different efforts, and we believe that should be reflected in your ability to follow the status of a work item.
Previously, if you wanted to follow a work item and get notifications on any changes made, you would get email notifications for any and all changes made to the work item. After considering your feedback, we are making following a work item more flexible for all stakeholders. Now, you will see a new settings button next to the Follow button on the top right corner of the work item. This will take you to a pop up that will let you configure your follow options.
From Notification Settings, you can choose from three notification options. First, you can be completely unsubscribed. Second, you can be fully subscribed, where you get notifications for all work item changes. Lastly, you can choose to get notified for some of the top and crucial work item change events. You can select just one, or all three options. This will let team members follow work items at a higher level and not get distracted by every single change that gets made. With this feature, we will eliminate unnecessary emails and allow you to focus on the crucial tasks at hand.
Link work items to deployments
We are excited to release a preview of the Deployment control on the work item form. This control links your work items to a release and enables you to easily track where your work item has been deployed. To learn more see the documentation here.
Use service account-based authentication to connect to AKS
Previously, when configuring Azure Pipelines from the AKS Deployment Center, we used an Azure Resource Manager Connection. This connection had access to the entire cluster and not just the namespace for which the pipeline was configured. With this update, our pipelines will use service account-based authentication to connect to the cluster so that it will only have access to the namespace associated with the pipeline.
Preview Markdown files in pull request Side-by-side diff
You can now see a preview of how a markdown file will look by using the new Preview button. In addition, you can see the full content of a file from the Side-by-side diff by selecting the View button.
Build policy expiration for manual builds
Policies enforce your team's code quality and change management standards. Previously, you could set build expiration polices for automated builds. Now you can set build expiration policies to your manual builds as well.
Add a policy to block commits based on the commit author email
Administrators can now set a push policy to prevent commits from being pushed to a repository for which the commit author email does not match the provided pattern.
This feature was prioritized based on a suggestion from the Developer Community to deliver a similar experience. We will continue to keep the ticket open and encourage users to tell us what other types of push policies you'd like to see.
Retry failed stages
To try this feature, you must have the preview feature Multi-stage pipelines enabled.
One of the most requested features in multi-stage pipelines is the ability to retry a failed stage without having to start from the beginning. With this update, we are adding a big portion of this functionality.
You can now retry a pipeline stage when the execution fails. Any jobs that failed in the first attempt and those that depend transitively on those failed jobs are all re-attempted.
This can help you save time in several ways. For instance, when you run multiple jobs in a stage, you might want each stage to run tests on a different platform. If the tests on one platform fail while others pass, you can save time by not re-running the jobs that passed. As another example, a deployment stage may have failed due to flaky network connection. Retrying that stage will help you save time by not having to produce another build.
There are a few known gaps in this feature. For example, you cannot retry a stage that you explicitly cancel. We are working to close these gaps in future updates.
Enhancements to approvals in YAML pipelines
You must have Multi-stage pipelines and New service connection experience preview features enabled to try this feature.
We continue to improve multi-stage YAML pipelines. With this update we have enabled configuring approvals on service connections and agent pools. For approvals we follow segregation of roles between infrastructure owners and developers. By configuring approvals on your resources such as environments, service connections and agent pools, you will be assured that all pipeline runs that use resources will require approval first.
The experience is similar to configuring approvals for environments. When an approval is pending on a resource referenced in a stage, the execution of the pipeline waits until the pipeline is manually approved.
Container structure testing support in Azure Pipeline
Usage of containers in applications is increasing and thus the need for robust testing and validation. Azure Pipelines now brings supports for Container Structure Tests. This framework provides a convenient and powerful way to verify the contents and structure of your containers.
You can validate the structure of an image based on four categories of tests which can be run together: command tests, file existence tests, file content tests and metadata tests. You can use the results in the pipeline to make go/no go decisions. Test data is available in the pipeline run with an error message to help you better troubleshoot failures.
Input the config file and image details
Test data and summary
Flaky bug management and resolution
In July we introduced flaky test management to support end-to-end lifecycle with detection, reporting and resolution. To enhance it further we are adding flaky test bug management and resolution.
While investigating the flaky test you can create a bug using the Bug action which can then be assigned to a developer to further investigate the root cause of the flaky test. The bug report includes information about the pipeline like error message, stack trace and other information associated with the test.
When a bug report is resolved or closed, we will automatically unmark the test as unflaky.
Enhancements to Azure Pipelines app for Slack and Microsoft Teams
Multi-stage YAML based pipelines
To try this feature, you must have the preview feature Multi-stage pipelines enabled.
The Azure Pipelines app for Slack and Microsoft Teams now supports multi-stage YAML pipelines for CI and CD. With this enhancement, you will get notified on various events related to YAML pipelines.
Events supported for multi-stage YAML pipelines
- Run state changed
- Run stage state changed
- Run stage waiting for approval
- Run stage approval completed
URL unfurling and messaging extensions
We've added a messaging extension for the Azure Pipelines app for Microsoft Teams. You can now search for pipelines and share relevant details about the pipeline as a card in the channel. URL unfurling helps you initiate discussions around pipelines and have meaningful & contextual conversations.
Updates to hosted pipelines images
We've updated several of the Azure Pipelines hosted VM images. The following are some the highlights in this update:
- Added Go 1.13 to Ubuntu 16.04, Ubuntu 18.04, VS2017, and VS2019. Go 1.12 remains the default.
- Added Android SDK and Build Tools 29 to Ubuntu 16.04, Ubuntu 18.04, VS2017, and VS2019.
- Added Az Module 2.6.0 to VS2017 and VS2019.
- Various bug fixes.
You can find more details about the latest releases here.
We will remove Ruby 2.3 from all images in a future update since it reached end-of-life on March 31, 2019.
Open Policy Agent installer task
Open Policy Agent is an open source, general-purpose policy engine that enables unified, context-aware policy enforcement. We've added the Open Policy Agent installer task. It is particularly useful for in-pipeline policy enforcement with respect to Infrastructure as Code providers.
For example, Open Policy Agent can evaluate Rego policy files and Terraform plans in pipeline.
task: OpenPolicyAgentInstaller@0 inputs: opaVersion: '0.13.5'
Pipeline decorators for release pipelines
Pipeline decorators allow for adding steps to the beginning and end of every job. This is different than adding steps to a single definition because it applies to all pipelines in an organization.
We have been supporting decorators for builds and YAML pipelines, with customers using them to centrally control the steps in their jobs. We are now extending the support to release pipelines as well. You can create extensions to add steps targeting the new contribution point and they will be added to all agent jobs in release pipelines.
Azure Test Plans
New Test Plans page
Most of the planning, authoring, executing and tracking capabilities are now available in the new Test Plans page. Hence, we are enabling it for all Test Plans users so they can provide us with feedback. The remaining few capabilities require for us to reach parity with the prior Test Plans page will be enabled in the next few sprints. If necessary, users can disable the Test Plans page on the Preview Features menu. Read more here.
Inline sprint burndown using story points
Your Sprint Burndown can now burndown by Stories. This addresses your feedback from the Developer Community.
From the Sprint hub select the Analytics tab. Then configure you report as follows:
- Select Stories backlog
- Select to burndown on Sum of Story Points
Short and readable Wiki page URLs
You no longer have to use a multiline URL to share wiki page links. We are leveraging the page IDs in the URL to remove parameters hence making the URL shorter and easier to read.
The new structure of URLs will look like:
This is an example of the new URL for a Welcome to Azure DevOps Wiki page:
This was prioritized based on this feature suggestion ticket from the Developer Community.
Mermaid diagram support in wiki
We've added support for inserting mermaid diagrams in wiki pages. You can now create, edit and manage flow charts, sequence diagrams in your design documents and add Gantt charts in your planning documents in Azure DevOps Wiki.
These features will roll out over the next two to three weeks.
Head over to Azure DevOps and take a look.
How to provide feedback
We would love to hear what you think about these features. Use the feedback menu to report a problem or provide a suggestion.
You can also get advice and your questions answered by the community on Stack Overflow.