2

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? sounds like a similar question, but it's not about a general approach, but how to solve version conflicts in poms.

1 Answer 1

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.

0

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.