Blog

Only trigger a release when the build changed

01 May, 2017
Xebia Background Header Wave

Back in the early days, when we used XAML builds in TFS (wow that seems like ages ago!), we had the possibility to NOT execute a build when nothing changed in the source code repository. This checkbox “Build even if nothing has changed” does not exist anymore in VSTS.
For me this is not a real problem, when you build your source code, it is also a validation if your underlying system is OK. It is more a problem when you automatically trigger a release pipeline after a nightly build. Why should you release a new version of your application, when it is not a new version but exactly the same version. Of course, we can discuss that it should not be a problem, that you should always be able to release, but still. It is unneccessary and sometimes even not wanted.

To overcome this, I created a small script and process to solve this issue.

  • The build is triggered nightly. I cannot stop this otherwise than a manual trigger
  • In this build I check if the CommitID that triggered the build is the same as the CommitID in the latest succesful build of the same definition
  • If it differs, I tag my build with a Tag. In my case “Release”
  • I set up my release pipeline to only release the build with this tag

The script
On my GitHub Repository you can find the whole script but I’ll talk you through some parts.
In this snippet, you can see that I first get the details of my current build. I retrieve this build by it’s ID. I sent this from my build pipeline where I use the Predefined Build Variable $(Build.BuildID)

1

Then I, use the Build Definition ID, to retrieve all the builds with the same definition and filter on only succeeded builds and take the latest.
Then I check the sourceversion, which is the CommitID and check if it is the same. If not, I tag the build with a Release Tag
Set up the pipeline
Then, in the Release Pipeline that deploys this build, I set up the trigger Tag, so that it only releases builds with the right trigger. I’ve described that in my previous blog post 
That’s it!. Now you can safely have a scheduled build and not worry about duplicate releases !
Full source can be found here!
2460 b.gif?host=roadtoalm

René van Osnabrugge
As Global Consulting Director, Rene enables consultants to help organizations and leadership teams to build an engineering culture that allows them to build, deliver, and operate software in a secure and compliant way. With a focus on both the technical and cultural aspects of a company, Rene helps clients transform their work processes, operating model, and culture to become high-speed, innovative, and productive. Rene is passionate about learning new technologies and exploring the cultural and people aspects of companies. He believes that by focusing on both technical implementation and cultural development, we can drive our industry forward. He loves sharing his knowledge and insights at conferences and training events. As a frequently asked speaker at well-known industry events like GitHub Universe, NDC, Techorama, AllDayDevOps, NDC, and Visual Studio Live!, Rene is known for his expertise in Microsoft Azure, DevOps, and DevOps Culture. In addition to being a Microsoft MVP since 2012, he is also the founder of the popular community events Global DevOps Bootcamp and Global DevOps Experience.
Questions?

Get in touch with us to learn more about the subject and related solutions

Explore related posts