0

I am seeing an error in our release build process. Need your help/suggestions on it.

In our organization, we follow the release strategy like this: our codebase has microservices/applications located on individual folders like this format

MS-A
MS-B
MS-C
MS-D

Our release processes follow this workflow:

branch-1 has made changes on MS-A and merged it to master
branch-2 has made changes on MS-B and merged it to master
from master we create Release branch R1 and did the release process, where only MS-A and MS-B gets deployed

afterwards similarly,

branch-3 has made changes on MS-C and merged it to master
branch-4 has made changes on MS-D and merged it to master
then from from master we create Release branch R2 and did the release process, where only MS-C and MS-D gets deployed

During release, we basically do a git diff R2 R1 and calculate which folders got updated, and then start deployment of only those folders(i.e. microservices).

Now when there is any error during deployment - we create a bugfix branch from master(which naturally gets ahead of the release branch HEAD now), push the fixed codes there, merge it to master and then we just cherry pick that commit id on the release branch and redeploy it.

So as a result, we had been seeing an issue occuring - when git diff is calculating the changes on two release branches, it isn't taking into account the cherry-picked ids as a part of the previous release but considering it as a part of the next release branch itself.

a short example using the previously described relese workflow example will easily visualize this error:

Lets say, on R1 release MS-A and MS-B got deployed and there was some issue with MS-A for which we raise a bugfix branch B-1. we push the commits on B1 and merge it to master and cherry-pick those commits onto R1 branch. Then after the release R1 is completed, we made changes on MS-C and MS-D and merged it to master and create new release branch R2. So if i do git diff R2 R1, i want the output to be MS-C and MS-D only, but here we get MS-A, MS-C and MS-D. Git is not considering cherry picked B-1 commits as a part of R1.

Considering the above scenario and keeping in mind I can't make any changes in the entire release workflow process whatsoever, is there any way to fix this issue?

Novice_coder
  • 31
  • 4
  • Please [edit] your question and create a [mre]. Instead of describing what you do, show example commands how you modify files, how you use Git and how exactly you detect the problem. – Bodo Nov 30 '21 at 16:15
  • So, to clarify, are the B-1 changes actually applied to MS-A in both R1 and R2 when you inspect them manually? If so, I don't see why the git diff would see them as different. I guess I wonder why you cherry pick B-1 to R2, if B-1 only applies to MS-A in R1... – joanis Nov 30 '21 at 22:49
  • @Bodo, Apologies for this type of cumbersome example, but couldn't think of any other easy way to explain the overall process – Novice_coder Dec 01 '21 at 11:45
  • @joanis, B-1 is merged to master, so when I create branch R2 from it, it automatically becomes a part of it. but as its cherry picked on top of R1 - so diff R2 R1 shouldn't show this common addition isn't it? – Novice_coder Dec 01 '21 at 11:47
  • @Novice_coder You can explain the process by showing in your question an exact command sequence to reproduce the problem like `git init`, `echo foo > foo`, `git add foo`, `git commit -m "add foo"`, `git checkout -b branch-1`, commands that add or modify files, commit, switch branch, cherry-pick, merge, etc... and show how you finally detect the problem – Bodo Dec 01 '21 at 11:54
  • @Novice_coder Indeed, if B-1 is actually part of both branches you're comparing, `git diff` should not report that as a difference. However, I am suspicious of your claim that it is not in there. When you cherry-pick from master to R2, it won't take all new commits on master, only the ones you explicitly list. `master` would only mean the very last commit on the branch, for example. – joanis Dec 01 '21 at 13:16
  • I think your next step is to use a visual log viewer that displays commits as a tree. Tig is a GUI example among many, though I like the simple command line `git log --all --decorate --graph --format=oneline`. Make sure the histories really show the commits you think are in each branch. And to get further help from the SO community, @Bodo is right, you'll need to show us a reproducible example. Because we're just trying to guess what you did at this point. – joanis Dec 01 '21 at 13:20
  • But the short answer to your question is: if `git diff` says there's a difference, then there's a difference. There's no escaping that. If you don't think there should be a difference, then you've created the branches incorrectly. Inspect the commit trees. Inspect the individual commits in full detail. Dig until you find what's not as you would expect. – joanis Dec 01 '21 at 13:22

0 Answers0