1

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

0

I have the exact same question. So sad nobody stopped to think the best option and respond.

For me the more correct one would be to have a separate job. Having a release branch that will end up having the code at the point of the last release (and never ever nobody will read code at that commits seems weird). Maybe have a separate job that will create a specific branch release/1.2.3 adn then create the release from there. After that the tag 1.2.3 is created and the relase/1.2.3 branch is deleted.

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.