<p>Some of the best practices I have used in the past for building releases with Jenkins multibranch pipelines and Git:</p>
<ul>
<li><p>It is recommended to use a release branch for building and deploying release artifacts. Merge the code into the release branch when ready to cut a release. The Jenkins pipeline can automatically build and deploy from this branch.</p>
</li>
<li><p>Use Git tags to trigger release builds. Tag the commit in the main branch when ready and configure the Jenkins pipeline to build whenever a new tag is pushed.</p>
</li>
<li><p>Avoid using long-lived branches. Instead, frequently merge short-lived feature branches back to the main branch to keep the release branch workflow cleaner.</p>
</li>
<li><p>I would recommended to use a consistent naming convention for branches, such as <code>feature/</code>, <code>bugfix/</code>, <code>release/</code>. This makes it easier to identify the purpose of each branch.</p>
</li>
</ul>

CC BY-SA 4.0
2024-04-23T09:00:22.157Z
2024-04-23T09:00:22.157Z
Thomas Vincent
<p>We have started moving from Subversion to git (using Bitbucket, to be exact), and I'm unsure how to manage release builds with the multibranch concept.</p>
<p>This is how we do it in Subversion:</p>
<p>We have one Jenkins job based on a declarative pipeline (Jenkinsfile). It has a parameter <code>isRelease</code> that is false by default. When we decide to build a release, a developer starts the job manually setting <code>isRelease</code> to true. In the pipeline there is a <em>Release</em> step that is run when <code>isRelease</code> is true, performing a Maven release.</p>
<p>I've been reading a lot about how to work with git branches, but I wasn't able to make a decision which concept to use for building releases. Jenkins doesn't seem to offer a manual build in multibranch jobs, so it looks like we have to change our approach. As I understand, there are many options, for example:</p>
<h3>(1) Use a second Jenkins job</h3>
<ul>
<li>create another Jenkins job specifically to manually start building a release</li>
</ul>
<p>This is close to how we are doing it now, but I feel it's actually not the way it should be done with git.</p>
<h3>(2) Use a release branch</h3>
<ul>
<li>create a <em>release</em> branch</li>
<li>when we decide to build a release, merge it into the <em>release</em> branch</li>
<li>have the Jenkins pipeline automatically create a release from the <em>release</em> branch</li>
</ul>
<p>The manual step would change from starting a Jenkins job to merging into the <em>release</em> branch, which appears to be more 'gittish' to me.</p>
<h3>(3) Use a develop branch</h3>
<ul>
<li>create a <em>develop</em> branch as the common branch during development</li>
<li>when we decide to build a release, merge it into the <em>master</em> branch</li>
<li>have the Jenkins pipeline automatically create a release from the <em>master</em> branch</li>
</ul>
<p>Similar to (2), just using the master branch differently.</p>
<p>Which option is the best and why? Are there other (better) options?</p>
<hr />
<p>Note that <a href="https://devops.stackexchange.com/q/4913/33747">What's the practice to perform a releasing with Git?</a> sounds like a similar question, but it's not about a general approach, but how to solve version conflicts in poms.</p>

<jenkins-pipeline><git><release>
Best practice for building releases with Jenkins multibranch pipeline
not2savvy
# Best practice for building releases with Jenkins multibranch pipeline

(Asked by: username_0 on 2022-10-02)

We have started moving from Subversion to git (using Bitbucket, to be exact), and I'm unsure how to manage release builds with the multibranch concept.

This is how we do it in Subversion:

We have one Jenkins job based on a declarative pipeline (Jenkinsfile). It has a parameter `isRelease` that is false by default. When we decide to build a release, a developer starts the job manually setting `isRelease` to true. In the pipeline there is a *Release* step that is run when `isRelease` is true, performing a Maven release.

I've been reading a lot about how to work with git branches, but I wasn't able to make a decision which concept to use for building releases. Jenkins doesn't seem to offer a manual build in multibranch jobs, so it looks like we have to change our approach. As I understand, there are many options, for example:

### (1) Use a second Jenkins job

* create another Jenkins job specifically to manually start building a release

This is close to how we are doing it now, but I feel it's actually not the way it should be done with git.

### (2) Use a release branch

* create a *release* branch
* when we decide to build a release, merge it into the *release* branch
* have the Jenkins pipeline automatically create a release from the *release* branch

The manual step would change from starting a Jenkins job to merging into the *release* branch, which appears to be more 'gittish' to me.

### (3) Use a develop branch

* create a *develop* branch as the common branch during development
* when we decide to build a release, merge it into the *master* branch
* have the Jenkins pipeline automatically create a release from the *master* branch

Similar to (2), just using the master branch differently.

Which option is the best and why? Are there other (better) options?

---

Note that [What's the practice to perform a releasing with Git?](https://devops.stackexchange.com/q/4913/33747) sounds like a similar question, but it's not about a general approach, but how to solve version conflicts in poms.

**Tags:** jenkins-pipeline, git, release


---

## 1 answers

### Answer by username_1 on 2024-04-23. Score: 2

Some of the best practices I have used in the past for building releases with Jenkins multibranch pipelines and Git:

* It is recommended to use a release branch for building and deploying release artifacts. Merge the code into the release branch when ready to cut a release. The Jenkins pipeline can automatically build and deploy from this branch.
* Use Git tags to trigger release builds. Tag the commit in the main branch when ready and configure the Jenkins pipeline to build whenever a new tag is pushed.
* Avoid using long-lived branches. Instead, frequently merge short-lived feature branches back to the main branch to keep the release branch workflow cleaner.
* I would recommended to use a consistent naming convention for branches, such as `feature/`, `bugfix/`, `release/`. This makes it easier to identify the purpose of each branch.


---

