Our first reason for using VSTS automated builds is to help us with Continuous Integration. Continuous Integration is defined as requiring developers to integrate code into a shared repository several times a day. Each checkin in then verified by an automated build, allow teams to detect problems early.
Under the “Build” tab in your VSTS dashboard, click the green + to add a new build definition. This will popup a list of templates to pick from. The new build system in VSTS (and TFS2015 >) is task-based. This allows you to define a list of things to do in a sequence.
I am going to choose “Visual Studio” to get started with. Click Next.
Next, pick the repository your solution is in. Mine is in the TFVC repositiory within VSTS. Check Continuous Integration – this will trigger your build everytime code is checked into the repository. Finally, pick your queue. I am picking the queue I created earlier – “Home”, but there is nothing to stop you building against the hosted agent queue provided by VSTS. Click Create.
This creates some default tasks. The first (and unlisted task) is for the agent to download the source of your application from the repository. Following this:
I am going to tweak my build definition to do the following:
Some of you may have spotted that I am creating a drop on my CI build. Why? Because I want to practice continuous deployment – I want to deploy to my automated test environment after every build that is performed.
There are a number of other tabs available while defining the build:
Have a look through as there are some useful options in there – however I will just highlight Triggers:
If you check Continuous Integration when creating the build, CI will already been checked by default. I would recommend checking “Gated Checkin” as well – when ever you check in, you will be prompted to verify the checkin with a build. This places your changes in a shelveset, and runs the CI build against that. If the build completes successfully, it will then auto-merge your shelveset of changes into the main repository.
Now you have completed your build definition, Save your build, and queue one to test it:
The build agent will provide a realtime output to the web interface:
That’s it. You’ve got a CI build up and running.
Once your first build it complete, you can view the build summary page:
This summary page will give a nice overview of any warnings or errors that occurred in the build, as well as your test results and code coverage.
That’s build done – next I am going to look at Release Management in VSTS to control the release process, and deploy to my environments in my deployment pipeline.