Hi,
I am struggling with a conundrum best explained in an example.
The scenario for the example below is simplistic, but it does surface in most development/maintenance workflows and is often mitigated with manual procedures or automated validation.
Scenario
Pete works on Jira Ticket E-123 and develop new functionality, changing seven existing programs. When he is done, he merge his code into the Trunk of the SVN and send the ticket to QA.
Then John works on Jira Ticket E-111 to to create other functionality. One of the existing programs he changes was changed by Pete as part of E-123. John merge his changes to the trunk and release the ticket to QA.
Mary is the system owner. She is satisfied with E-111 and decides to include it in the next release. The QA team also suggest a refinement in E-123 and Mary refers it back to Development.
However, production does not have the new code of E-123, as did QA, and the common program between E-123 and E-111 is not compatible with production.
How can the team detect that there is in fact a relation between E-111 and E-123 and that both MUST deploy simultaneously, i.e. that E-111 CANNOT be included in the next release?
We were hoping that Mylyn can be used to detect this inter dependency in order to alert John to the fact that he must relate his ticket to E-123. Is this possible? Is there a better solution?
Regards
Simon
Hi Simon,
Why don't you use branches ? In this case, you will have on your SVN server your two tickets in separated 'projects' + the merged version in trunk.
When you need to get just one Ticket in production, you just need to get the part in the good branche ...
The example does use branches for development. They converge into the trunk - which is the "potential product" that goes through QA before the next release is branched off as a maintenance branch.
The problem arise AFTER the branches converged, which they should do in the QA phase. It would be reckless to test each change independently and then hope they will play nice when moved to production.
When the branches had an overlap, there are only a few sane options if one is held back:
a) Hold back both.
b) Restore QA to a point before the merge and merge only the selected change. Repeat all testing.
Option a) is much cheaper than option b). In many cases option a) works, but I know from experience that every software house will often select option b) for cash flow reasons.
All of that is fine and accepted as normal.
The problem at hand is to detect such a overlap / conflict, as that is the only time this becomes an issue.
In the case where a merge conflict occurs with the overlapping program, the second committer will notice and can report the otherwise unknown relation. But in most cases source will merge successfully without generating a conflict, as SVN will only consider it a conflict if both versions changed at the same place.
theoretically QA has to test E-111 separately and E-123 separately, too - both in their own branch. Then, when it is decided which goes and which stays, all those that go are merged into a new Release-Branch, and the whole system tested. During the merge into this Release-Branch, the merging of E111 and E-123 changes happen; that is, the program that was changed for E111 and E123 gets both changes applied. At this time, both Pete and John would need to agree that the merge is ok, and only then can QA start testing.
Once the Release-Branch is tested and potentially changes backed out (and rest retested), it can be used for the release into production. Only, once it is released, this release can and should get merged back into trunk.
Trunk is what is in production. Everything else is in a branch...
At least that's the theory...
In practice, shortcuts happen. And sh...t happens...
When John merges his changes to the trunk, he should add a link in JIRA that E-123 is blocking E-111. That should be enough for QA to determine the dependency.