How to detect that unrelated changes has related source files - Forum - Community Groups - Progress Community

How to detect that unrelated changes has related source files

 Forum

How to detect that unrelated changes has related source files

  • 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

    Simon L Prinsloo

    www.vidisolve.com

  • This request may have been better asked on a JIRA forum, however I will answer it here.

    We use the 'Link' functionality in JIRA, from E-111 and add a link to denote that E-111 is "blocked by" E-123.  E-123 will automatically be linked as "blocking" E-111.

    Given that the QA team have suggested a refinement in E-123, a further, more philosophical discussion can take place - should E-123 be released as is and the refinement added/coded during the next sprint (as it's own User Story/Bug).  

    This, of course, can only be determined on a case-by-case basis by answering the question whether or not the 'working' functionality has more value being released in its current form, with a follow up change to refine the functionality, or whether the QA suggestions are actually showstoppers.