CODEWITHSUNDEEP
jenkinsjenkins-pipeline
Neil
Neil

Reputation: 2610

Multibranch Pipeline vs Pipeline job

Now that the Multibranch Pipeline job type has matured, is there any reason to use the simple Pipeline job type any longer? Even if you only have one branch today, it's probably wise to account for the possibility of multiple branches in the future, so what would the motivation be to use the Pipeline job type for your Jenkins Pipeline vs. always using the Multibranch Pipeline job type, assuming you are storing your Jenkinsfile in SCM? Is there feature parity between the two job types now?

Upvotes: 38

Views: 27689

Answers (6)

user25713260
user25713260

Reputation:

Scenario: 2024

1. Pipelines:

Way A: Single branch (develop):

  • Workflow:
    • All devs merge to develop and push.
    • Jenkins runs the pipeline:
      • If successful, merge to main.
      • If it fails, git reset --hard to revert the changes.

Way B: One job for each branch:

  • Workflow:
    • Each dev commits their individual branch.
    • Jenkins runs pipelines for each job:
      • If successful, merge to main.
      • If it fails, git reset --hard.

2. Multibranch Pipelines:

  • Workflow:
    • Each dev works on their own branch and commits.
    • Jenkins automatically detects the new branch and runs the Jenkinsfile from that branch.
    • If all goes well:
      • Optional: Delete the branch.
      • Merge with develop.
    • If develop is stable, merge with main.

Key Differences:

  • Pipelines (Form A): Higher risk of collisions and conflicts in develop.
  • Pipelines (Form B): More manual configuration needed.
  • Multibranch Pipelines: Automation, lower risk of conflicts, and increased efficiency in projects with multiple active branches.

Essentially, Multibranch Pipelines offer a more scalable and efficient solution, especially in environments with multiple developers and active branches.

Upvotes: 0

Harry Urcen
Harry Urcen

Reputation: 35

There exist a lot of CI/CD tasks not related to GIT/source code. For example, preparing docker images, provisioning different kind of testing environments, cleaning ups and so on. For this cases you don't need to use multibranch approach. it just makes the things more complicated.

Using a multibranch plugin for source code processing proposes 2 things:

  1. Source code in all branches should be handled the same way.
  2. Jenkinsfile described the pipeline included to the source code tree. Otherwise, using the multibranch plugin becomes tricky.

Of course, you can change a pipeline behavior depending on branch/pr. But I believe it's a bad practice. Unfortunately, I meet this practice all the time and it looks ugly and sometimes cause issues if the pipeline needs a significant update.

Upvotes: 0

jonathan ezroni
jonathan ezroni

Reputation: 36

If you are still developing your flow, the simple pipeline has the added advantage of supporting parameterized projects. This feature is useful for developing the declarative pipelines in the jenkins gui, using the parameter to control what branch/repository you are targeting.

Upvotes: 0

nick w.
nick w.

Reputation: 149

Multibranch Pipeline works well if your Jenkins job deals with a single git repository. On the other hand, the pipeline job can be repository-neutral and branch-neutral and very flexible when working with multiple git repositories with a single Jenkins job.

For example, assume you have artifact-1 from repo-1, artifact-2 from repo-2, and integration tests from repo-3. And artifact-2 depends on artifact-1. A Jenkins job has to build artifact-1, then build artifact-2, and finally run integration tests from repo-3. And assume your code change goes to a feature-1 branch of repo-1 and feature-1 branch for new tests in repo-3. In this case, the Jenkins job builds feature-1 for artifact-1, then uses 'dev' branch as default from repo-2 (if feature-1 is not detected in repo-2), and runs 'feature-1' from repo-3 for new integration tests. As you can see, the job works well with three git repositories. A repo-neutral/branch-neutral pipeline job is ideal in this setting.

Upvotes: 7

emmdee
emmdee

Reputation: 1621

In my experience with multibranch pipelines, the ONLY downside is that you can't see the last success/failure/duration columns on the Jenkins main page. They just show "NA" on the Jenkins front page since it's technically a 'folder' of sub-jobs.

Other than that I can't think of any other "cons" to using multibranch.

I disagree with the other answer.... that case was that multibranch sends changes for "any" branch. That's not necessarily true. If a Jenkinsfile exists on a random feature branch, but that branch is not defined in the pipeline then you can just not do anything with it using typical if/else conditionals.

For example: 

node {
  checkout scm
  def workspace = pwd()

  if (env.BRANCH_NAME == 'master') {
    stage ('Some Stage 1 for master') {
      sh 'do something'
    }
    stage ('Another Stage for Master') {
      sh 'do something else here'
    }
  }

  else if (env.BRANCH_NAME == 'stage') {
    stage ('Some stage branch step') {
      sh 'do something'
    }
    stage ('Deploy to stage target') {
      sh 'do something else'
    }
  }

  else {
    sh 'echo "Branch not applicable to Jenkins... do nothing"'
  }
}

Upvotes: 13

tommy tom
tommy tom

Reputation: 39

In a CI/CD situation, it may not be desirable to send every branch to the target environment. Using pipeline and specifying a single branch would allow you to filter, and send only /master to Staging or Production environments. Multibranch would be useful for sending any change on any branch specifically to a test environment.

On the other hand, if the QA/AutomatedTesting process is thorough enough, the risk with sending any branch to Production could be acceptable.

Upvotes: 3

Related Questions