What is the best practice for a multibranch pipeline configuration?

Question

I'm messing around with a multibranch pipeline in jenkins. Currently we have zero pipelines in production and everything is using freestyle jobs which is very sloppy. I have my own multibranch pipeline using my name to get my branches, checking which ones have a Jenkinsfile. I'm sure there's no one great answer to this, but what is the general use of a multibranch pipeline? Do people create one per user? What is your current or your favorite setup for this?

If this isn't the place to ask a "best practice" question, please point me to a devops forum or somewhere that I might be able to ask this.

Answer 1

Multi branch pipelines work great when your are using the git flow method: https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow

We define one multi branch pipeline per application. There is one pipeline documentation for all branches. Based on the branch name different artifacts are build in the end.

• Main branch builds release artifacts. This could be replaced with builds on git Tag events. The release artifacts will be deployed by fixed version numbers to the test and production environment.
• Develop branch builds Snapshot artifacts. Those will be deployed by using latest to the develop environment.
• Feature branches build also Snapshot artifacts which can be deployed to the dev environment as well.

All commit events on all branches run lint, unit test, SAST, dependency scan checks before the artifact is pushed to the artifactory. This guarantees that you don’t have to remediate a lot of findings after merging into the develop or main branch. Using different artifactories helps you reduce storage costs because you can just delete all Snapshot artifacts after 30 days.

Feel free to ask for specific details.

Cheers!

Answer 2

With traditional free-style jenkins jobs, you're limited to building only what is explicitly checked out by the build, which is typically main (or trunk if using svn). If you make a branch then you could duplicate the main job and change the checkout to get your branch instead of main. If you're branching infrequently then this might not be an issue but otherwise gets quite tedious!

With a multibranch pipeline, if a new branch has been created then a job will automatically be created for it and then run. This saves the overhead of manually creating them.

An excellent resource is the Jenkins book: https://www.jenkins.io/doc/book/pipeline/

Answer 3

When using the forking git workflow, each engineer has their own separate server-side repository. In Jenkins, to work with this setup, you'll need to create a separate multibranch pipeline for each engineer. This is because Jenkins looks at one repository at a time along with its branches and open pull requests when making a multibranch pipeline.

So, in a nutshell, with the forking git workflow, Jenkins needs individual multibranch pipelines for each engineer to handle their repositories, branches, and pull requests separately (if you're using the forking workflow). That's why you were able to create a multibranch pipeline with your own repo.