Visual Studio Online, CI and CD in Azure

CI (ContinuousIntegration) and CD (Continuous Delivery) are nowadays solid best practices in Software Development, aimed at reducing at a minimum the risks involved with releasing software.

The idea is simple: the more often you release your software, the more chances are you won’t bump into deployment issues (ie: problems during the release).

Microsoft TFS (Team FoundationServer) has been used for long to address this needs, but since a few years (in particular since CloudComputing and Azure became a trend), it has gradually been replaced by its online version VSTS (Visual Studio Online Team Services).

While setting up CI and CD in VSTS is not rocket science, it helps to know some basic concepts before starting.

To start setting up Continuous Integration, you need to access the Build & Release tab in your VSTS instance.

NOTE: One important thing to keep in mind is that Build and Release are separate activities, and to have a full CI you need to configure them both individually.

Here you will be able to manage all your Build Definitions, as shown here; if no definition is present, you can easily create one.

Once you click on an existing Build Definition, you will see the log of your previous builds, with their version, status, code branch, etc.

If you click on the Edit button on the top right of this page, you will open the Build Definition in Edit Mode, so you can configure its steps (or Tasks).

Here, as you can see, you can configure common Tasks, such as Get source (from Git or other repositories), NuGet restore, and several other common Build Tasks.

Setting up those Tasks is straightforward; you just need to specify the configuration details based on your application.

NOTE: The Publish part of the Build Definition could be misleading at first, as everything that gets “published” is placed within VSO for the subsequent Release Definition to pick it up.

Basically Build creates the Artifacts within the $(build.artifactstagingdirectory) folder of VSTS, and Release will pick them up from there, and deploy them to the final environment.

So, once the Build is properly configured you can run it and verify that everything works fine (the Get sources Task will guarantee that a Build is automatically triggered whenever there is a Commit in Source Control for the selected code branch, or you can always Queue a new build manually).

You can see the progress of each build by opening its page, as shown here.

Next step is to configure the Release Definition.

By clicking on the Releases tab on the top of VSTS, you open the list of Release Definitions.

If no Release Definition is present, you can create one, and then you start by adding an Environment where you want to deploy your application, and then configure Tasks similarly to what you did in the Build Definition.

Here also you have plenty of common Tasks used for deployment, such as Configuring an Azure App Service or Slot App Settings, Deploy, etc.

When the Release Definition is configured properly, after each successful Build, a Release will be automatically triggered, and if all Tasks are successful your application will be deployed to your environment.

And that’s it, now you can enjoy your CI and CD on VSTS!