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.