How many pipelines for Trunk Based Development?

Question

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.

---

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?

Answer 1

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).