Azure DevOps Project is in public preview as announced here.  This article provides an overview of the preview's functionality.

Azure DevOps Project - What is it?

Visual Studio Team Services (VSTS) is Microsoft's highly customizable DevOps platform supporting team collaboration, project management tooling, continuous integration (CI) and continuous delivery (CD).  Azure DevOps Project is a simplified experience of bringing solutions onto the VSTS platform.  In its current preview state, setup is a wizard experience guiding you from selecting either a pre-defined template or an existing GitHub repository for setting up the CI/CD services to deploying to Azure.  Once the solution is deployed, DevOps presents a new dashboard view linking everything together.


A new DevOps Project blade is available in the portal and can be found by searching for devops:

A new DevOps Project can be started by selecting Add:

Select a new application to bring into VSTS

The first step allows for a template to be selected or a GitHub repository.  For this walkthrough a .NET web app will be selected.

It is interesting to explore the Bring your own code option though.  If this option is selected then a GitHub private repository can be selected.  It is also possible to select an External GitHub service also but not a VSTS repository.  This does make sense as the idea of the DevOps is streamlining the onboarding process of moving onto VSTS.  The GitHub selection is illustrated below:

Selecting Application/Framework

The next step is selecting the specific framework.  In this example, a choice of ASP.Net or ASP.Net Core is available:

Service Configuration

Bringing the selected application onto VSTS is made extremely simple whether it is a new VSTS account or an existing one.

An important thing to note is the Azure service to be deployed can be configured including the pricing tier and app service location:


 Pretty straightforward but what do we end up with?  A pretty dashboard that at a glance tells us we deployed something really cool that normally would have taken a lot longer to complete.  

CI/CD Pipeline

 The CI/CD Pipeline is an excellent summary of our project.  We can easily see the status of each stage including build numbers and branch names.  Handy references are also available to take us immediately to either the code, build definition or release definition.  For example, if we use the reference in the release section:

Then we are taken into VSTS to the release summary:

Application Insights

 Another nice feature is Application Insights is provisioned and all wired up as part of the template:

So why is this so cool?

Besides fast-tracking the process there are several subtleties that might be overlooked at first glance.  The DevOps Project has put together many best practices and made adoption close to painless.  For example, implementing CI and CD does take time and could be thought of as a nice to have especially when a project is starting up.  DevOps Project implements this as a first step. 

To illustrate this take continuous integration on code check-in.  If the Build pipeline is investigated and the definition reviewed the triggers can be reviewed showing that the build will start (and even batch when a build is in progress) with each change to the master branch:

Why this is cool is now the team has a build definition and a release definition that can be tailored to their particular requirements.  

More information: