The Continuous Delivery Tools for Visual Studio shipped last month as a Microsoft DevLabs extension to experiment with some of the latest ideas for setting up and working with a DevOps pipeline. As with any experiment the goal is to learn and test our hypotheses. The enthusiasm and feedback has validated just how much opportunity there is to help developers continuously deliver value to their users. We’ve shipped several incremental updates that fix bugs and other minor usability improvements. Our latest update has several new improvements:

• Support configuring a continuous delivery pipeline for a repository hosted on GitHub
• Improvements that make it simpler to getting started
• Notifications for all Builds you trigger manually, through a CI event or with a PR

Let’s walkthrough some of these improvements.

Configuring Continuous Delivery for a repository hosted on GitHub

After we released the extension one of the first items users asked about was how do I use this extension to setup a continuous delivery pipeline if my code doesn’t live in a Git repository on Visual Studio Team Services? GitHub and TFVC were the two most popular requests. This update adds support for Git repositories on GitHub and we’re looking at adding support for TFVC in the future.

If you have the GitHub extension for Visual Studio installed, the ‘Add to Source Control’ button in the status bar will setup a repo and push your code up to GitHub in a couple clicks.

Then, right click on your ASP.NET project in Solution Explorer and select “Configure Continuous Delivery…”. The wizard has a new field to enter your GitHub Personal Access Token (PAT) so Team Services can listen for commits and trigger a build & release whenever code is pushed into the GitHub repository.

Another observation from the first release was some users were not able to successfully setup a Continuous Delivery pipeline. When we dug in to the data, we found many users were failing because they were missing one of the prerequisites needed to get everything setup on VSTS. Some common case were users running the wizard on projects that were not under version control or users who did not have an Azure Subscription. We’ve made some improvements to help users with those prerequisites and over time we’ll integrate them directly into the experience so it’s all one step.

Notifications for builds you trigger manually, through a CI or with a PR

We heard lots of feedback around what DevOps activities should produce a notification in the IDE as well as when and where they should appear. Some users wanted to track all CI results. Some users wanted only failures. Some wanted failure results for specific projects. It was clear throughout the feedback that configuration would be critical to meet the broad set of requirements. Notifications for events “I” triggered was as theme that resonated with most users we interviewed.

In this update, we’ve pivoted our notification experience to generate failed, fixed, or success notifications for all builds you triggered in Team Project for your active repository. Now you’ll see a notification the first time you Configure a Continuous Delivery pipeline using the extension and then every time you trigger a build which can happen automatically with a code push or pull request, or manually from Team Services. We’ve also started investigating how we can offer a more complete configuration experience on Team Services that will expand the set of notifications you can receive in the IDE.

It’s all about feedback

First, a thank you to everyone who has reached out and shared feedback and ideas so far. We’re always looking for feedback on where to take this Microsoft DevLabs extension next. There’s a Slack channel and a team alias vsdevops@microsoft.com where you can reach out to the team and others in the community sharing ideas on this topic.

, Principal PM Manager, Visual Studio Platform IDE @ACangialosi Anthony has focused his career at Microsoft on building developer technologies. He is the program manager for Visual Studio’s Connected experiences and IDE. Anthony joined the Visual Studio team in 2001 and has contributed experiences across the IDE including VS’s identity infrastructure the Shell, the VS SDK, Ecosystem, VSIP, and mobile device development