When a developer needs to set aside their work in progress, Shelveset Validation Build becomes a handy tool. Whether the work stops due to interruption, collaboration, code review, backup, or handoff, pending changes can be moved to a shelveset on the server and it saves and restores file revisions, comments, a list of related work items and check-in policies.
In Team Foundation Version Control, developers have the ability to create shelvesets of local pending changes, directly from Visual Studio. This acts as a backup of your local changes directly on the Azure DevOps Server. The fact that the shelveset is stored on the ADO server, means that it provides some additional functionality such as using it as the Source Code of a Pipeline Build, these are called Shelveset Validation Builds.
Shelveset Validation Builds are useful to confirm that the code you are working on locally, not only compiles and builds locally but also on the server you build your application on, in this case Azure DevOps Build Agents.
If a DevOps environment is configured in a way that pipelines can ship directly to different environments, such as a Dev or Testing Server, shelveset builds can also assist in getting those changes deployed quickly, before checking them into the shared repository.
Prerequisites
Assuming you already have a running project Repository and Pipeline on Azure DevOps, we will be making use of TFS Version Control (TFSVC).
Our Repository for the project we are working on:
The Pipeline for our project:
Firstly, we need to be sure that our pipeline is in working order with the latest source code before we start queuing builds for a shelveset. This will assure us that if the build breaks for whatever reason, the cause is indeed in a change we have made and not because of a pre-existing broken build:
The changes to the Shelveset build
Queuing a build for changes we wish to validate is a really simple process; firstly, we need some changes:
As seen in the screenshot above, we have made a relatively simple change. For this first example, we will go through a change that should not break our current build.
Queueing the Build
To queue a build for our local changes, we first need to get them to the server but we should not check them in. To do this we need to create a shelveset of our local changes:
Step 1: Evaluate your local changes
Keep in mind that whatever is in the ‘Included Changes’ section of the Pending Changes menu, will be included in our build. So, if we were working on multiple projects or repositories, this would need to be cleaned up to avoid kicking off Pipelines we do not wish to queue right now.
Step 2: Create a shelveset
Working with shelvesets is relatively easy and is a safe way to make sure your local changes are backed up to the Azure DevOps server. To create a shelveset, all we need to do is select the ‘Shelve’ menu in the “Check In” section of the “Pending Changes” menu in Team Explorer and give the shelveset a name:
Here you can choose to preserve your changes locally, which will be useful if the shelveset validation fails, and we need to make some fixes to the code.You can also choose to Evaluate policies for notes, related work items etc. that may be set up for our repository.
Once we are happy with our shelveset, all we need to do is click “Shelve”:
Step 3: Queue a Pipeline Build
To queue our Pipeline for the shelveset we just created, we need to navigate to the Pipeline on Azure DevOps and click “Run pipeline”:
As seen above on the Run Pipeline popup, we have the ability to specify a Shelveset name. Click on the elipses in order to browse your current shelvesets:
Choose your shelveset and click “ok”.
The build can now be queued:
When we inspect the view above, we can see that it specifies the build as “Validate shelveset”. This would also be an easy way to identify shelveset validation builds from other developers in your team.
It is also worth noting that you are not limited to queuing shelveset builds only for your own shelvesets. At the shelveset picker, you can also specify a different developer’s name:
In conclusion, are shelveset builds the right choice for your development team? If you are working in an environment where building locally does not necessarily mean it will build on the server, this feature would assist with your accuracy. The process can also assist with getting testable builds deployed in your development environment without needing to check into the source control or do manual deployments.
What to understand with shelveset builds, is that it behaves like a normal build. If you have an automated release pipeline linked to it, it will still automatically deploy. In the case where this is not desired, gates and approvals will most likely, need to be implemented. Some development cultures would also need to be adapted for your team to understand the intention of the Shelveset validation builds being queued on your servers. A benefit to this is that it can be worked into your definition of done in some cases, making a passing shelveset build part of the requirements for sending a code review. The possibilities are nearly endless on where it can add value.
Morne Kellerman