0

Following below git-flow,

enter image description here

Using CI/CD approach for SDLC, if a tagged commit passed QA pipeline, then it is time to create Release branch from Develop branch, because my understanding is,

If prod pipeline build fails on merge with Master branch, then developers need to fix that issue first and create a new working commit on the same Release branch. This may lead to code freeze time for developers to merge in Develop branch, for the reason, Release branch merge with Develop branch(after prod pipeline gives success) MUST not throw errors in dev pipeline.

My question is, as shown below,

enter image description here

Does Master merge duration requires a code freeze time for other developers on Develop branch? If yes, Is codefreeze breaking the principles of continuous delivery?

overexchange
  • 15,768
  • 30
  • 152
  • 347
  • I'm not sure you can get a definitive answer on this though, it may be prone to being based on opinions. My opinion is that after you've created the release branch, if you find any critical bugs that must be fixed before releasing, you fix them using a branch *from* the release branch, and merged *back into* the release branch. The develop branch, however, should be free to be worked on while this happens. – Lasse V. Karlsen Jan 16 '19 at 17:22
  • @LasseVågsætherKarlsen After fixing bugs in Release branch, when release branch gets merged with Develop branch, what if Dev pipeline gives error? because other developers have merged into Develop branch in that time frame. **Main point** is, **Release** branch merge with **Develop** branch should not break the build dev pipeline – overexchange Jan 17 '19 at 18:15
  • 1
    Well, then you fix the errors. I really don't know what to say here. – Lasse V. Karlsen Jan 17 '19 at 19:43
  • @LasseVågsætherKarlsen Am trying to say that, code freeze for that release merge duration is better than fixing errors. But does it breaks principles of continuous delivery? – overexchange Jan 17 '19 at 19:45

1 Answers1

2

Yes, I think such approach deviates significantly from the CI principles. It probably falls into the CI Theatre scope. And without CI you can't really talk about CD.

The general idea behind CI is for all development to be broken in small, incremental changes, developed as close as possible to the tip of the branch and immediately integrated into the branch to maximize visibility and keep surprises at a minimum. Only in such conditions the CI tool can be effective in pointing out most problem commits very fast.

Going away on a side branch (frozen or not) while the master branch keeps moving implies an extra effort for merging that branch with the master (in any direction), increasing in difficulty proportionally with the lifespan of the side branch. That's because the merge attempts to smash together 2 bigger lumps: all commits from the branch and all commits done on master since the branch was pulled/sync'd - no longer an incremental change. The ability to immediately identify a faulty commit is lost, it's an all or nothing decision: either you allow the merge, taking the hit in quality or reject it. This is why IMHO:

  • talking about doing CI on branches is almost immediately suspect
  • CI (as a methodology) is pretty much synonymous to trunk-based development (TBD).

Release branches are a bit different that regular branches, they can make sense in some business cases. But only if they remain true to CI by not being subjected to merges. The point of a release branch is, indeed, freezing - isolating it from the development on the trunk, which continues evolving towards the next release. Merging a release branch back into trunk doesn't make a lot of sense to me: changes for an older version aren't necessarily compatible with the newer version, such merge is just asking for trouble. See also my answer to How to get rid of develop branch for simplified Git flow. If there are valuable commits on the release branch (the usual reason for requesting such merge) they should be verified for compatibility and double-committed in the trunk as independent changes, submitted to the same verification criteria as any other trunk changes.

Note: I'm not saying non-CI strategies won't work - most of them do (I worked with them for years) but they're harder, slower and more expensive.

Dan Cornilescu
  • 39,470
  • 12
  • 57
  • 97