This is part 2 of the DevOps with VSTS series
Continuous Integration is the automation of building and testing code every time a developer integrates changes into a shared repository.
Automating this step enables us to commit changes to the repository very fast and, using unit tests, verify if the changes introduces a bug.
Knowing very quickly if a change introduced a bug, makes it easier to the fix the bugs since the developer is still in the context of that change.
Setting up a Continuous Integration in VSTS is very easy.
This post will show how to set up the following items:
First start with creating a new VSTS project.
In a later post a custom Work Item Process will be created. For now, select the Agile process since it's most suited for DevOps.
When the project has been created, clone the repository locally and commit a project to it.
The source code for the sample project used in this post can be found on GitHub
In VSTS browse to the source code under Code => Files and there select Set up build
The goal of the CI build is to automate the process of creating a release package.
By automating this step, the release package will always be created in a reliable and consistent way.
Select the Visual Studio Build Template and in the next page enable Continuous Integration.
The sample application that I'm using for this post, is an ASP.NET MVC5 website.
To enable the creation of a release package during the build, MSBuild needs to be configured to create a webpackage.
To do this, in the Build solution step, the following MSBuild Arguments need to be provided: /p:DeployOnBuild=true /p:WebPublishMethod=Package /p:PackageAsSingleFile=true /p:SkipInvalidConfigurations=true /p:PackageLocation="$(build.stagingDirectory)"
Continuous Integration should give as much information about the build as possible.
Therefore I choose to also enable Code Coverage in the Test Assemblies step.
When done, save the template and give it a name like "My Build - CI".
With these steps done, the CI build has already been set up. There's not that much to it.
You can try it by committing a new change and you will see the build being triggered. If everything is OK, VSTS should show that the build has succeeded.
When the build has finished, there should now be a release package available for this build. This can be seen by selecting the build => Artifacts => Explore.
For the sample project there should be a webpackage. This is the zipfile named "DevOpsWithVsts.Web.zip"
With the CI build in place, every commit to the repository will now trigger a build which can be used to determine the quality of the last commit.
However, in DevOps (or Agile/Scrum for that matter) the master branch should always be in a deployable state.
This means that at any given moment in time, it should be possible to deploy the master branch into production.
To achieve this a gated build can also be added. The goal of the gated build is to act as a gatekeeper for the master branch.
Before any code is merged into the master branch, the quality of the change should already have been verified. This is what the gated build, together with Pull Requests, will do.
The gated build will be very similair to the CI build, so we can use the CI build as a template for the gated build.
To set up the gated build, first browse to the build definitions under Build & Release => All definitions.
Then click on the ellipsis button for the CI build and click on Clone.
Since the gated build is used to verify the changed code, the build doesn't need to produce any artificats and should be as fast as possible.
Therefore, the "Publish symbols", "Copy files" and "Publish artifacts" steps can be deleted.
When done, save the template and give it a name like "My Build - Gated".
At this point, the gated build has been configured correctly. To start using it, the next step is to modify the branch policies for the master branch.
Using Branch Policies, the required flow for any changes can be forced.
To set up the gated build, first browse to the repository management under Code => Manage repositories.
After that, select the master branch and then select Branch Policies.
In the Branch Policies the following changes have been made:
Automatically build pull request
Select the gated build in the dropdown, select Always require a new build and select Block pull request until a valid build.
With these settings VSTS will disable the ability to directly commit changes into the master build.
Instead developers need to create a new branch, commit changes to that branch and create a pull request to merge the changes into the master branch.
After creating a pull request VSTS will trigger the gated build on a temporary version of the new branch master merged with the master branch.
As long as the gated build fails, it wil not be possible to finish the PR and thus merge the changes into the master branch.
Work item linking requirements
By enabling the check for linked work items and blocking the PR for as long as no work items has been linked to the PR, VSTS forces a developer to allow for his work to be tracked.
By forcing the linking, we make the work more visible and the entire lifecycle of a work item can be tracked.
Code review requirements
By enabling a minimum number of approvals for a PR, we improve the collaboration and sharing of knowledge within the team.
It furthermore stimulates a high-trust environment because there is more of a feeling of shared responsibility between the developers who created the changes and those that reviewed the changes.
With all components of the Continuous Integration in place, the next steps is to make CI status easily visible to the entire team.
In VSTS browse to the project dashboard and click the Edit dashboard button.
To focus on the CI status, add the Chart for Build History and the Test results trends widgets.
Configuration of these two widgets is extremely easy. For both simply select the CI Build as the definition source and that's it.
There are a lot more interresting and helpfull widgets available in the VSTS marketplace. So do have a look what widgets more can help to improve visibility in the quality and status of the build.
For example, one other awesome widget is the Code Coverage Widget
As the name predicts, this widget shows the Code Coverage percentage of the last build.
With these widgets added, the dashboard looks like this.
Using the wrench button on the dashboard page, the dashboard can be configured to automatically refresh.
This is very useful if for instance the dashboard is put on a large monitor in the teams office so everyone can monitor the status of the build.
With Continuous Integration completely set up, the next thing is to set up Continuous Delivery.
How this can be done in VSTS, is shown in the next post Continuous Delivery