3

For Gitflow based workflow, three pipelines(Dev, QA & prod) are recommended.

My understanding is, if there are 2-3 developers in a single team, with short-lived feature branches which commit changes in predefined time(24 hrs), then Trunk based development is preferred, as shown below. Developers on a team are committing their changes to the trunk(master) multiple times a day.

enter image description here

Advantage using TBD:

With TBD, there is a master branch and multiple Release branches from master.

where as

With Gitflow, there are multiple Release branches from long-lived Develop branch.

1) Using TBD, How many pipelines are required using Jenkins?

2) What is the input/output of each pipeline?

overexchange
  • 15,768
  • 30
  • 152
  • 347
  • I don't think I understand your 2nd question, can you elaborate, pls? – Dan Cornilescu Jan 18 '19 at 22:03
  • @DanCornilescu In gitflow approach, Dev pipeline gets triggered(input) on commit and delivers a snapshot binary artifact(output). QA pipeline polls SCM for any new tagged commit and then picks the corresponding snapshot binary artifact for testing... Prod pipeline gets triggered on commit on master branch and delivers a release binary artifact. – overexchange Jan 18 '19 at 22:14

1 Answers1

3

Personally I would prefer Trunk based development regardless of the team size :)

The number of release branches isn't really dictated by the methodology used (TBD or something else), but rather by business reasons:

  • release branches are used for products that really need different, more or less frozen releases, like OS-es or embedded systems, for example. Typical reasons for such needs include:
    • significantly long time required to verify all release quality criteria, stabilizing the software requires isolating the release from the continued development towards the next release in order to meet those criteria
    • multiple releases need to be maintained at the same time - the release branches become the vehicles for delivering any per-release hot-fixes
  • if there is no hard requirement for separate release branches releases can become nothing more than tags/labels on the primary development and integration branch - this is really what true CD boils down to. The CI/CD pipeline is executed for every commit and, whenever it passes all release criteria the release is out.

You'd need one Jenkins pipeline for every release branch and one for the primary development branch (if you're not releasing directly from it).

Dan Cornilescu
  • 39,470
  • 12
  • 57
  • 97
  • If all the team branch from trunk for multiple features, then, is this manageable? – overexchange Jan 19 '19 at 04:35
  • If the feature branches are short lived it's way easier to manage than the branch spagetti. Especially in large projects. – Dan Cornilescu Jan 19 '19 at 13:20
  • I think you have a point. In your experience, do you think, Feature branches can be small in pure development project( agile based)? Say a web development project... Is there a way to know that two developers are working on same file but different branches? – overexchange Jan 19 '19 at 13:23
  • Can we have a quick chatroom discussion? – overexchange Jan 19 '19 at 13:32
  • In my experience features were typically large, feature branches weren't short lived. So we switched to feature flags and branch by abstraction and dropped these branches completely, everyone was working on the main branch. But we used a gated commits CI system as a regular one couldn't keep up - huge team. – Dan Cornilescu Jan 19 '19 at 13:39
  • Let us [continue this discussion in chat](https://chat.stackoverflow.com/rooms/186968/discussion-between-dan-cornilescu-and-overexchange). – Dan Cornilescu Jan 19 '19 at 13:42