This post series provides the latest updates and news for Visual Studio Team Services and is a great way for Azure users to keep up-to-date with new features being released every three weeks. Visual Studio Team Services offers the best DevOps tooling to create an efficient continuous integration and release pipeline to Azure. With the rapidly expanding list of features in Team Services, teams can start to leverage it more efficiently for all areas of their Azure workflow, for apps written in any language and deployed to any OS.
Azure Red Shirt Dev Tour: Our VSTS account
Scott Guthrie has been traveling the world on a tour he’s called the Azure Red Shirt Dev Tour. As part of that, he shows the account our team uses to build VSTS. That’s right – we use VSTS to plan, build, test, and release VSTS. See what VSTS looks like for a large team in Scott’s demo of VSTS using our account (mseng.visualstudio.com) – showing ongoing work on VSTS live on stage – from the New York City stop on the tour. If you want to go deep on how our team works, check out DevOps at Microsoft.
Roadmap Update
We periodically update our roadmap of new features we have planned for VSTS. We just published our latest update, and it’s our largest yet.
Generate YAML templates from existing build definitions
Last year we announced the public preview of YAML builds that enable you to configure your build process as a YAML file checked in with your code rather than with the graphical build definition editor. We’ve now made it simpler for you to convert your build definitions in the web UI into a YAML file. In the build definition editor for your build, you can select the Process tab on the left and then click the View YAML link in the pane on the right. Copy the text to the clipboard and check in a file with the contents into your repo. Then configure a new build YAML based build definition that references the checked in file.
This can also be used as a good way to learn YAML quickly. You can create a new build definition using the appropriate template for your app and examine the YAML to understand the mapping between what you’re used to and the new YAML constructs. Here are a couple more resources to get you started with YAML builds (later this year we will also have YAML for Release Management).
Enhancements to multi-phase builds
NOTE: To use this capability, you must have the Build with multiple queues preview feature enabled on your account.
We recently added phases to build definitions. You’ve been able to use phases to organize your build steps and to target different agents using different demands for each phase. Now we’ve added several capabilities to build phases so that you can now do the following.
-
Specify a different agent queue for each phase. This means you can, for example:
- Run one phase of a build on a macOS agent and another phase on a Windows agent. To see a cool example of how useful this can be, see this Connect(); 2017 video: CI/CD DevOps Pipeline for mobile apps and services.
- Run build steps on a build agent pool and test steps on a test agent pool.
-
Run tests faster by running them in parallel. Any phase that has parallelism configured as “Multi-agent” and contains a “VSTest” task will now automatically parallelize test execution across the configured agent count.
-
Permit or deny scripts to access the OAuth token each phase. This means, for example, you can now allow scripts running in your build phase to communicate with VSTS over REST APIs, and in the same build definition block the scripts running in your test phase.
-
Run a phase only under specific conditions. For example, you can configure a phase to run only when previous phases succeed, or only when you are building code in the master branch.
To learn more, see Phases in Build and Release Management.
Run UI tests and install software on Hosted VS2017 agents
We’ve had a lot of customers ask us for the ability to install software on the hosted build agents because there’s something their builds need but isn’t available in the image. Now you can do that. If you’re using the Hosted VS2017 queue, your build and release tasks now run as administrator, in interactive mode. This means you can now use this hosted pool to run UI tests and install whatever software you need. Because we re-image the build agents after every build, each build starts with a clean environment.
Release triggers branch enhancements
You can now configure a release trigger filter based on the default branch speciffied in the build definition. This is particularly helpful if your default build branch changes every sprint and the release trigger filters needs to be updated across all the release definitions. Now you just need to change the default branch in build definition and all the release definitions automatically use this branch. For example, if your team is creating release branches for each sprint release payload, you update it in the build definition to point to a new sprint release branch and release will pick this up automatically.
Identify flaky tests
One of the core tenets of DevOps is to have reliable and fast automated tests. Sometimes tests are flaky where they fail on one run and pass on another without any changes (of course, it could be the product code and not the tests that are flaky). Flaky tests are frustrating and undermine the team’s confidence in the tests. Left unchecked, the team will ignore flaky tests as noise, resulting in bugs slipping through to production. We’ve now deployed the first piece of a solution to help tackle the problem of flaky tests. You can now configure the Visual Studio Test task to re-run failed tests. The test results then indicate which tests initially failed and then passed on re-run. That’s a key step in identifying flaky tests that need to be investigated and fixed. Support for re-run of data driven and ordered tests will be coming later.
The Visual Studio Test task can be configured to control the maximum number of attempts to re-run failed tests and a threshold percentage for failures (e.g. only re-run tests if less than 20% of all tests failed) to avoid re-running tests in event of wide spread failures.
In the Tests tab under Build and Release, you can filter the test results with the Outcome “Passed on rerun” to identify the tests that were flaky during the run. This will currently show the last attempt for each test that passed on re-run. The Summary view shows “Passed on rerun (n/m)” under Total tests, where n is the count of tests passed on re-run and m is total passed tests. A hierarchical view of all attempts is coming in next few sprints.
Build with the appropriate agent by default
When you use one of our templates to create a new build definition, we now select a hosted agent queue for you by default. For example, the Ant and Maven templates default to the Hosted Linux queue. Xcode and Xamarin.iOS templates default to Hosted macOS Preview. The ASP.NET Core template defaults to Hosted VS2017. Of course, you can still change the queue to your preference, but this default saves some time when defining a new build process and otherwise avoids having to re-set the appropriate agent queue.
Use VSTS as a symbol server
VSTS is a symbol server, which enables you to host and share symbols with your organization. The symbol server functionality is now generally available. Symbols provide additional information that makes it easier to debug executables. See the publishing symbols for debugging for more information.
This feature was prioritized based on a top suggestion.
Blame now has history
The Blame view is great for identifying the last person to change a line of code. However, sometimes you need to know who made the previous change to a line of code. The newest improvement in blame can help – View blame prior to this commit. As the name suggests, this feature allows you to jump back in time to the version of the file prior to the version which changed a particular line, and view the blame info for that version. You can continue to drill back in time looking at each version of the file that changed the selected line of code.
View pull request merge commit
Pull request diff views are great at highlighting the changes introduced in the source branch. However, changes to the target branch may cause the diff view to look different than expected. A new command is now available to view the diff of the “preview” merge commit for the pull request – View merge commit. This merge commit is created to check for merge conflicts and to use with a pull request build, and it reflects what the merge commit will look like when the pull request is eventually completed. When the target branch has changes not reflected in the diff, the merge commit diff can be useful for seeing the latest changes in both the source and target branches.
Another command that’s useful in conjunction with the View merge commit command is Restart merge (available on the same command menu). If the target branch has changed since the pull request was initially created, running this command will create a new preview merge commit, updating the merge commit diff view.
Integrate using the pull request status API and branch policy
Branch policies enable teams to maintain high quality branches and follow best practices during the pull request workflow. Now, you can use the pull request status API and branch policy to integrate custom tooling into pull request workflows. Whether it’s integrating with a 3rd party CI/CD solution, or enforcing your own internal process requirements, the status API can help. We’re using this extensively in our own PR processes for building and testing code prior to completing each pull request. Check out our code, samples, and documentation for more information.
View Analytics Widgets as a Stakeholder
Installing the Analytics extension adds 6 powerful widgets to your widget catalog: Cumulative Flow Diagram, Lead Time, Cycle Time, Velocity, Burndown, and Burnup. Now, those with the free Stakeholder license can view all the Analytics widgets too!
To use the Analytics OData endpoint or Power BI to connect to Analytics, a Basic license is still required.
Integrate Power BI with VSTS Analytics using new views
The default views in the VSTS Power BI Desktop Connector help you get started on working with VSTS data right away. We’ve added additional views with common historical definitions to allow you to more easily perform trending and bug analysis. Refer to our guidance on connecting to VSTS with Power BI Data Connector for more information.
In the upcoming February release of Power BI Desktop, we will introduce the ability to create your own views, which will make working with the specific data you need in Power BI even easier.
Discuss work items in Microsoft Teams using the VSTS messaging extension
Microsoft Teams has become the hub for teamwork within many engineering teams. We have expanded our Microsoft Teams integration with the new VSTS messaging extension to enable you to find and discuss specific work items alongside your other content and tools. See the Microsoft Teams Integration extension in the Marketplace for more information.
Move work using suggested Areas and Iterations
It can be common to work in the same area or iteration and repeatedly browse through the hierarchies when moving work items around. The Area and Iteration path controls now include a list of recently used values as Suggestions, giving you quick access to set and move on.
In addition, Iteration dates are included to the right of the name so that you can quickly judge when a work item should be delivered.
Wiki Search now Generally Available
After a public preview of Wiki search in December, we are now making it generally available. You can search for your favorite wiki pages by title or content right alongside code and work items.
Manage access and extensions for large numbers of users using groups
We’ve made it easy for administrators to manage large groups of users by enabling you to assign access levels and extensions to AAD or VSTS groups. After setting up the appropriate rules, adding someone to the group will automatically grant them the correct access levels and extensions when they access the VSTS account. As a result, access levels and extensions will no longer have to be managed on an individual basis.
See the large account user management roadmap post on the Microsoft DevOps Blog from last year for more information.
Cloud Solution Provider purchasing now generally available
Purchasing from Visual Studio Marketplace via the Cloud Solution Provider (CSP) program is available for all offers/markets where CSP is supported today. CSP partners across those markets can now purchase Visual Studio subscriptions, Visual Studio Team Services Users, 1st party extensions (e.g. Test Manager, Hosted Pipelines, Package Management) from Visual Studio Marketplace for their customers. Visual Studio Marketplace will now recognize and accept Azure CSP subscriptions for all 1st party purchases now. In addition, CSPs can also manage Visual Studio subscriptions they purchased for their customers through our subscription management portal, setup VSTS accounts from Azure portal, and link existing VSTS accounts to Azure CSP subscriptions to take over the billing from their customers.
Extension of the month: Pull Request Conflict Resolution in the Browser
Last year we moved the entire Windows code base into a single Git repo using something we created called Git Virtual File System. Once the entire Windows team was using Git, they needed a more convenient way to resolve conflicts for some of their workflows. The Windows team built a new extension to VSTS that allows you to resolve pull request conflicts directly in the browser, and I’m excited that it’s now available to everyone as an extension in the VSTS Marketplace.
Before a Git pull request can complete, any conflicts with the target branch must be resolved. With this extension, you can resolve these conflicts on the web, as part of the pull request merge, instead of performing the merge and resolving conflicts in a local clone.
Here’s what the experience looks like when you have a conflict after you’ve installed the extension.
Clicking on the file listed, you’ll be presented with a view to see the previous version and the new version so you can choose which content to keep.
You also choose to edit the combined file manually.
Wrapping Up
As always, you can find the full list of features in our release notes. Be sure to subscribe to the DevOps blog to keep up with the latest plans and developments for VSTS.
Happy coding!