Microsoft-hosted Linux and macOS agents generally available – VSTS Sprint 137 Update
In the Sprint 137 Update of Visual Studio Team Services (VSTS), we remove the "Preview" moniker from our Linux and macOS Microsoft-hosted CI/CD agents and make them generally available. Along with our Microsoft-hosted Windows agent, you now have a trusted and scalable platform for production builds and releases, no matter what your platform.
There are a number of other features across Code, Wiki, Package, and Administration. Check out the Features list below for more.
These features will be rolling out over the next two to three weeks.
Read about the new features below and head over to VSTS to try them for yourself.
- Create pull requests without a default team as reviewer
- Allow bypassing branch policies without giving up push protection
- Link to headings within a page
- View broken links
- Attach files and images in folders
- Open page in new tab
Build and release:
- Build and release with Microsoft-hosted Linux and macOS agents
- Automatically deploy to new targets in a deployment group
- Hold deployments until gates succeed consistently
- Azure DevOps Projects now generally available
- Connect or disconnect Azure Active Directory as a Project Collection Admin
- Public projects available in preview for all accounts
Create pull requests without a default team as reviewer
To use this capability, you must have the New Navigation preview feature enabled on your profile or account.
When we first launched the pull request (PR) experience, we thought it would make sense to assign all PRs to the team context that you had selected when creating the PR. This behavior has been a frustration point, since many people did not notice the connection between the team context and the PR assignment. In fact, this has been one of our top UserVoice suggestions. As part of the new navigation changes, we took the opportunity to change this default association with teams. You'll notice two changes:
- When creating a PR, no reviewers are added by default. The reviewers list does have a feature to make it easier to add individuals and groups that were added to PRs recently. The required reviewers policy can also help teams that want to ensure that specific reviewers are added to review their code.
- The Pull Requests hub has a new customizable section. By default, this section shows PRs "Assigned to my teams", providing equivalent functionality as the old section. However, if you belong to multiple teams, this section will show PRs assigned to any of your teams. The section is also customizable - just click on the "Customize this view" action near the section header.
Allow bypassing branch policies without giving up push protection
There are many scenarios where you have the occasional need to bypass a branch policy - reverting a change that caused a build break, applying a hotfix in the middle of the night, etc. Previously, we offered a permission ("Exempt from policy enforcement") to help teams manage which users were granted the ability to bypass branch policies when completing a pull request. However, that permission also granted the ability to push directly to the branch, bypassing the PR process entirely. To improve this experience, we've split the old permission to offer more control to teams that are granting bypass permissions. There are two new permissions to replace the old one:
- Bypass policies when completing pull requests. Users with this permission will be able to use the "Override" experience for pull requests.
- Bypass policies when pushing. Users with this permission will be able to push directly to branches that have required policies configured.
By granting the first permission and denying the second, a user will be able to use the bypass option when necessary, but will still have the protection from accidentally pushing to a branch with policies.
This change does not introduce any behavior changes. Users that were formerly granted Allow for "Exempt from policy enforcement" will be granted Allow for both new permissions, so they will be able to both override completion on PRs and push directly to branches with policies.
See the Set branch permissions documentation for more information.
Link to headings within a page
Now you can click the link icon next to any section heading in a wiki page to generate a URL directly to that section. You can then copy that URL and share it with team members to link them directly to that section. This feature was prioritized based on a suggestion.
View broken links
All links in a wiki that are not linked properly will appear in a distinct red color and broken link icon, giving you a visual clue of all broken links in a wiki page.
Attach files and images in folders
While editing wiki pages offline it can be easier to add file attachments and images in the same directory as the wiki page. Now, you can add an attachment or an image in any folder in the wiki and link it to your page. This feature was prioritized based on a suggestion.
Open page in new tab
Now you can right click on a wiki page and open it in new tab or simply press CTRL + left click on a wiki page to open it in a new tab.
Build and Release
Build and release with Microsoft-hosted Linux and macOS agents
The Microsoft-hosted Linux and macOS agents are now out of preview and generally available. After several months in preview, listening to feedback, and tuning the infrastructure to provide a consistent service, we're excited to offer these now in GA. See the Microsoft-hosted agents documentation for more information.
Automatically deploy to new targets in a deployment group
Previously, when new targets were added to a deployment group, a manual deployment was required to ensure all targets have the same release. You can now configure the environment to automatically deploy the last successful release to the new targets. We plan to add additional trigger events and actions to the auto redeploy configuration in coming sprints. See the Deployment Groups documentation for more information.
Hold deployments until gates succeed consistently
Release gates enable automatic evaluation of health criteria before a release is promoted to the next environment. By default, the release progresses after one successful sample for all gates has been received. Even if a gate is erratic and the successful sample received is noise, the release progresses. To avoid these types of issues, you can now configure the release to verify consistency of the health for a minimum duration before progressing. At run time, the release would ensure consecutive evaluations of the gates are successful before allowing the promotion. The total time for evaluation depends on "time between reevaluation" and would typically be more than the configured minimum duration. See the Release deployment control using gates documentation for more information.
Azure DevOps Projects now generally available
Back in November we introduced DevOps Projects, which helps ou get up and running with a full DevOps pipeline on Azure, from code through monitoring, in just a few minutes. We've added services along the way and incorporated a lot of your feedback. We'll now continue moving forward with it in generally availability to help you go even further on your journey with DevOps. See the Azure DevOps Projects general availability post on the Microsoft DevOps Blog for more information.
Get started with pre-installed Package Management
The Package Management extension is pre-installed into all accounts. If you're using the new navigation preview, look for it at the bottom of the list of services. If you're still on the current navigation, look for the Packages hub in the Build and release hub group. Each account comes with 5 free Package Management users, and additional users can be purchased from the Marketplace. Manage extensions using the menu in the top-right of the navigation.
Connect or disconnect Azure Active Directory as a Project Collection Admin
A Project Collection Administrator (PCA) can now connect or disconnect their account from Azure Active Directory. Previously this had to be done by an account owner.
Public projects available in preview for all accounts
To use this capability, an account administrator must enable public projects from the Settings page.
As we announced back in April, we're bringing public projects to VSTS. For the first time, you'll be able to mark a VSTS Team Project as public. This will enable anonymous (un-authenticated) users to be able to view the contents of that project, including work items, code, and build results. Although the feature is still in preview, as of this sprint you will no longer need to be invited to join the private preview.
If you're using a public project to build a repository hosted on GitHub, note that while pull requests (PRs) from branches within your repository will build fine, PRs opened from forks of your repository will not build right now.
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.