Jenkins is a good CI/CD tool – we’ve talked about it extensively – but it’s a master-of-none for a lot of things, one being branched builds.

It’s risky to have everyone operate within the main build, especially if there’s a chance of deploying a release before it’s ready. A branched build – a build separate from your main build – is a great solution for this, since it creates an isolated environment for developers to make features or perform tests.

What is a Branched Build and Why it’s Good

Googling “what is branch builds” can get mixed results, but I found a definition that aligns with Inedo’s philosophy of Continuous Integration:

“A branch is a copy of a codeline, managed in a version control system (VCS). Branching helps software development teams work in parallel. It separates out “in-progress work” from tested and stable code.”

Remember that phrase: “Branching helps software development teams work in parallel.” That is the main draw of branch builds. When a source control system is properly set up to do it, you can use branches very powerfully and work in tandem with multiple teams.

Imagine you want to add a brand new feature to your software, but the main build is well-polished. You don’t want to risk your code messing with the main build, so you can create a branch and implement the feature there. When the feature is ready, you can bring it back into the main build and release! 

This type of control opens many possibilities for a team, from simple hotfix branches to stakeholders sponsoring proofs-of-concept.  

How to Make a Branched Build in a CICD Tool

The benefits are great, but how can you actually set it up?

Well, branches are encouraged by developers and tools alike; even Jenkins themselves says they “provide more dynamic and automatic functionality.” And yet Jenkins has only recently branched support and many users report the function feels like an afterthought.

It’s not easy to make branches using Jenkins. Consider this posted question by a StackOverflow user. They made the build parameterized and used Git as the source code management. But, the branch_name variable was not resolved from the project parameter.

The user figures they can “manually change branch name for every build,” but of course, that’s not ideal.

Compare this experience to the CI/CD tool BuildMaster.

In BuildMaster, you can get a source from a Branch in Git (via Branch: dev for example), or you can use OtterScript and specify the variable instead (via $BranchName).

It’s available as a drop-down menu item as soon as you start a build in BuildMaster.

The $BranchName variable can be set from multiple options, like via a Build API or programmatically determined at build-time in OtterScript using custom logic.

Use Branches to Expand Your Project

Regardless of the tool you use, it’s great to start considering branch builds in your operation. They offer great benefits like developing releases in parallel, experimenting in isolation, and boosting productivity with feature branches.

When started in the wrong tool, like Jenkins, managing branch builds can be hard. Software delivery pipelines are designed for repeatable processes, so tools like Jenkins are not flexible enough to deal with parallel releases.

BuildMaster simplifies the complications and allows users to customize to their needs. You could create branches unique to each release by creating branches in your source control with the same release number and checking out from the $ReleaseNumber branch. Or you could implement custom logic to determine which branch to build from using OtterScript.

Try branching out with your new or upcoming projects with BuildMaster! It’s available to download for free, forever, or request a key for a trial of the paid version.