This post series provides the latest updates and news for Visual Studio Team Services (VSTS) 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.

This month we’ll take a look at the new release definition editor, an update on the new wiki, improvements in pull requests, and how you can quickly get started building your own extension for VSTS. Let’s get started with a look at the latest release experience improvements.

New Release Definition Editor

The new Release Definition Editor going into preview. It is based off the new CI editor we released not long ago, and it’s a good example of the overall direction that we are going. It’s not just a cleaner experience, it is structurally different in that it lets you visualize your release process. It lets you work with Release in the way you think about your system. We are going to be bringing this same approach to the runtime views as well so that you can visualize a release as it progresses. Unlocking all of your data with richer, easier to consume visualizations is something we are trying to do across the product.

Visualization of the pipeline

The pipeline in the editor provides a graphical view of how deployments will progress in a release. The artifacts will be consumed by the release and deployed to the environments. The layout and linking of the environments reflects the trigger settings defined for each environment.

In context configuration UI

Artifacts, release triggers, pre deployment and post deployment approvals, environment properties and deployment settings are now in-context and easily configurable.

Applying deployment templates

The list of featured templates are shown when creating a new environment.

Improved task and phase editor

All the enhancements in the new build definition editor are now available in the release definition editor, too. You can search for tasks and add them either by using the Add button or by using drag and drop. You can reorder or clone tasks using drag and drop.

Code information in Release with Jenkins CI

In Release, we want to have better integration with popular CI systems like Jenkins. Today, in the release summary tab, we show code commits only if the CI build is coming from VSTS. This feature enables code information for Jenkins CI artifacts as well when the Jenkins server is reachable by the agent executing the release.

Release status badge in Code hub

Today, if you want to know whether a commit is deployed to your customer production environment, you first identify which build consumes the commit and then check all of the release environments where this build is deployed. Now this experience is much easier with the integration of the deployment status in the Code hub status badge to show the list of environments that your code is deployed to. For every deployment, status is posted to the latest commit that was part of the deployment. If a commit is deployed to multiple release definitions (with multiple environments) then each has an entry in the badge, with status shown for each environment. This improves the traceability of code commit to deployments.

Ansible extension

We have released a new extension that includes a build and release task to integrate with Ansible and execute a given Playbook on a specified list of Inventory nodes via command line interface. Ansible uses Playbooks which express configurations, deployment, and orchestration steps in YAML format. Each Playbook maps a group of hosts to a set of roles. Each role is represented by calls to Ansible tasks. An Inventory file is a description of the host nodes that can be accessed by Ansible.

The task requires that the Playbook and Inventory files be located either on a private Linux agent or on a remote machine where an Ansible automation engine has been installed. An SSH endpoint needs to be set up if the Ansible is located on a remote machine. Inventory can also be specified inline, as Dynamic Inventory, or as a Host list.

Improvements in the Wiki edit experience

As I mentioned last month, each project in VSTS now supports its own Wiki, and it continues to improve every sprint. Let’s look at some of the latest enhancements.

The new Wiki edit experience now supports HTML tags in markdown.

You can also conveniently resize images in the markdown folder.

Revert a Wiki revision

As you use Wiki more, there is a chance you’ll save unintended changes. Now you can revert a revision to a Wiki page by going to the revision details and clicking on the Revert button.

Learn more about getting started with Wiki.

Git pull request status extensibility in public preview

Using branch policies is a great way to increase the quality of your code, not only through code reviews, but also through automated builds and tests. Until now, those policies have been limited to only the integrations provided natively by VSTS. Using the new PR Status API and the corresponding branch policy, third party services can participate in the PR workflow just like native VSTS features.

When a service posts to the Status API for a pull request, it will immediately appear in the PR details view in a new Status section. The status section shows the description and creates a link to the URL provided by the service. Status entries also support an action menu that is extensible for new actions to be added by web extensions.

Status alone does not block completion of a PR – that’s where the policy comes in. Once PR status has been posted, a policy can then be configured. From the branch policies experience, a new policy is available to Require approval from external services. Select + Add service to begin the process.

In the dialog, select the service that’s posting the status from the list and select the desired policy options.

Once the policy is active, the status will be shown in the Policies section, under Required or Optional as appropriate, and the PR completion will be enforced as appropriate.

To learn more about the status API, and to try it out for yourself, check out the documentation and samples.

Automatically complete work items when completing pull requests

If you’re linking work items to your PRs (you are, right?), keeping everything up to date just got simpler. Now, when you complete a PR, you’ll have the option to automatically complete the linked work items after the PR has been merged successfully. If you’re using policies and set PRs to auto-complete, you’ll see the same option. No more remembering to revisit work items to update the state once the PR has completed – VSTS will do it for you.

Task lists in pull request descriptions and comments

When preparing a PR or commenting, you sometimes have a short list of things that you want to track but then end up editing the text or adding multiple comments. Lightweight task lists are a great way to track progress on a list of to-dos as either a PR creator or reviewer in the description or a single, consolidated comment. Click on the Markdown toolbar to get started, or apply the format to selected text.

Once you’ve added a task list, you can simply check the boxes to mark items as completed. These are expressed and stored within the comment as [ ] and [x] in Markdown. See Markdown guidance for more information.

Ability to “Like” comments in pull requests

Show your support for a PR comment with a single click on the like button. You can see the list of all people that liked the comment by hovering over the button.

Clean up stale branches

Keeping your repository clean by deleting branches you no longer need enables teams to find branches they care about and set favorites at the right granularity. However, if you have a lot of branches in your repo, it can be hard to figure out which are inactive and can be deleted. We’ve now made it easier to identify “stale” branches (branches that point to commits older than 3 months). To see your stale branches, go to the Stale pivot on the Branches page.

Search for a deleted branch and re-create it

When a branch is accidentally deleted from the server, it can be difficult to figure out what happened to it. Now you can search for a deleted branch, see who deleted it and when, and re-create it if you wish.

To search for a deleted branch, enter the full branch name into the branch search box. It will return any existing branches that match that text. You will also see an option to search for an exact match in the list of deleted branches. Click the link to search deleted branches.

If a match is found, you will see who deleted it and when. You can also restore the branch.

Restoring the branch will re-create it at the commit to which it was last pointed to. However, it will not restore policies and permissions.

Copy work item processes

You can now create a copy of an inherited process to use as a starting point for a new process, or to prepare and test process changes.

If you make a change to the process that is used by one or more team projects, each of these team projects will see these changes immediately. Often, that is not what you want. Instead, you want to bundle the changes to your process and test your changes before they are rolled out to all team projects. You can do this by following these steps:

1. Create a copy of the process that you want to change.
2. Make your changes to the duplicated process. Since no team project is using this process, these changes are not affecting anyone.
3. To test your changes, create a test project based on this duplicated process if you don't have any yet. If you have already created a test project before, you can change the process of the test project using the Change team project to use option from the context menu.
4. Now it is time to deploy the changes. To do this, you change the process of the team projects which need the new changes. Select the Change team project to use option from the context menu.
5. Optionally, you can disable or delete the original process.

Updated order of the last column in the Kanban board

If you added a custom state to your work item type, you might have noticed that the last column on the Kanban board always presented the card that was closed earliest. We’ve found that seeing the card closed most recently is often more helpful.

The root cause of this behavior is that the last column of the Kanban board is ordered descending on the Closed Date field. In our processes (Scrum, Agile, CMMI), each work item type includes rules to set this field when it is transitioned to the Closed or Done state (depending on the process and work item type). However, if you add a custom state we didn't automatically add rules to set the Closed Date field to support the new state. If you’d move a work item from the New state to the Closed or Done state, the Closed Date would have an empty value. Our query engine puts empty values on top when ordering descending. So on the Kanban board, you would see the cards on top that were closed earliest.

We first made sure that we are adding the right set of rules to the work items in case you are adding a custom state. You will not see an empty Closed Date anymore when closing a work item. We will not backfill existing closed work items. To ensure that you will see the most recently closed cards on the top in the Kanban board, we have also updated the ordering logic on the last column of the Kanban board to put cards with empty values for the Closed Date field at the bottom.

Velocity Widget for Analytics

The Analytics extension now includes a Velocity widget.

With this powerful widget, you can chart your team’s velocity by Story Points, work item count, or any custom field. With advanced options, you can compare what your team delivered as compared to plan, as well as highlighting work that was completed late.

The Velocity Widget provides functionality not available in the Velocity Chart displayed on the Backlog view, such as:

• Show velocity for any team, not just the current team
• Show velocity for any backlog level or work item type, not just the Stories backlog.
• Calculate velocity by sum of any field, not just Story Points. Or, by count of any work item type.
• Show planned vs. actual. Did you deliver what you actually planned?
• Highlight work that was completed late, after the sprint.
• It supports sizing to 1×1, for when you just want a tile to show your average velocity.

If you haven’t already, install the Analytics Extension to get access to the Velocity Widget as well as widgets for Lead Time, Cycle Time, and a Cumulative Flow Diagram.

We will be publishing more widgets for the Analytics Extension in the coming months, such as Burndown, Burnup, and Trend.

Extension of the month: SpecFlow+LivingDoc

SpecFlow+LivingDoc is now available in the Marketplace. Living documentation is the term used to describe system documentation that is up-to-date and easily understood. A prime example of this are feature files written in Gherkin, which uses natural language to describe how an application is expected to behave in a given scenario. By describing specifications in a natural language, all stakeholders (business, development, testing, requirements etc.) can understand and discuss the specifications on an equal footing. These specifications, in turn, form an important part of the system documentation, and are commonly used in agile development methods such BDD and Specification by Example.

For many .NET developers, the open source project SpecFlow is their tool of choice for automating test scenarios written in Gherkin with Visual Studio. However, these Gherkin files are plain text files, and are generally stored in a code repository and inaccessible to many team members. While the SpecFlow Visual Studio extension supports syntax highlighting for Gherkin in Visual Studio, not all stakeholders have access to Visual Studio, in particular, business stakeholders.

SpecFlow+ LivingDoc bridges this gap, making the specifications written in Gherkin accessible to all team members in VSTS. SpecFlow+ LivingDoc is part of SpecFlow+, a series of (optional) paid extensions for SpecFlow. SpecFlow+ LivingDoc takes your feature files and parses them so that they can be displayed in VSTS with syntax highlighting and formatting. This makes the feature files much easier to navigate than plain text without any formatting.

Formatting includes the following:

• Gherkin keywords syntax highlighting
• Tables
• Alternating background colors for Given/Then/When sections
• Support for images embedded via Markdown

Quickly get started writing your own extension

Over the last few years we have introduced a number of ways to extend and integrate with VSTS. For example, we have client libraries for .NET (which work with both .NET Framework and .NET Core apps) and for Node.js. We also have an extensibility model that allows extension of our web experience.

With all of these great options, the challenge is knowing what pieces you need to get started and then assembling them in the right way. We have made a lot of improvements to our integration docs and are planning another wave of improvements to our docs soon, but sometimes you need more than docs.

In a new blog post, The fastest path to a new VSTS extension, we show you how to quickly get started building your own extension.

There is always much more in each release than I can cover here. Please check out the July 14th and August 4th release notes for more information. Be sure to subscribe to the DevOps blog to keep up with the latest plans and developments for VSTS.

Happy coding!

@tfsbuck