As an enterprise customer for two releases (branches/tags/commits) I want to see a list of what issues were solved and which issues were involved.
Why do people need this? (PCI) compliance
How it works technically?
- Figure out the new git SHA1's between the two points
- Figure out which merge requests introduced these SHA1's
- Figure out which issues these merge requests these SHA1's solved.
We have all information for this, just requires some fancy interface. Nice idea.
Hardest part here is maintaining the issue granularity as changes get bundled up moving from branch to branch to branch. For example imagine the following branching structure:
[Feature_1] ------ [Integration master] --- [QA branch] --- [Pre-prod] ---- [Prod]
So all three feature branches are being built off of the Integration master branch...
Feature_1 gets merged into [Integration master] via MR1
Feature_2 gets merged into [Integration master] via MR2
Feature_3 gets merged into [Integration master] via MR3
Getting this data out of the [Integration master] branch should be easy.
But what happens then [Integration master] is merged to [QA branch] via MR4 which includes all 3 features in one big merge. Additionally assume MR5 and MR6 also add a bunch of stuff to the [QA branch].. MR7 merges all code from [QA branch] to [Pre-prod], then eventually all code is merged to [Prod].
If you are diffing two tags/commits on Prod to determine what changed, will the traceability back to issues 1, 2 and 3 still be there? Git alone won't give you this information. Especially troublesome if Feature branches are deleted and/or rebase/squash has been enabled. It might be necessary to track the relevant data in separate table during merge acceptance and then reference that data later via the UI.