Re: Percolating QC changes

In the Centralized CMS model typically used in the IBM i environment, you would check out the objects that needed changes, make the changes, and then promote the objects back to QC. If any of the objects that need changes are already checked out, the source for those changes must be saved out somewhere and the objects checked back in first. Then the conflicting development changes can be manually merged back in when the QC changes are completed. This is a common problem with centralized CMS systems like Aldon, Implimenter, and Turnover. This can sometimes be mitigated by each developer having his own development library. Then you only have to worry if the developer has the same object checked out for a different issue. That is easier to manage, but increases the storage requirements significantly.

Mark Murphy
Atlas Data Systems
mmurphy@xxxxxxxxxxxxxxx


-----Justin Taylor <JUSTIN@xxxxxxxxxxxxx> wrote: -----
To: "MIDRANGE-L (midrange-l@xxxxxxxxxxxx)" <midrange-l@xxxxxxxxxxxx>
From: Justin Taylor <JUSTIN@xxxxxxxxxxxxx>
Date: 03/02/2017 08:59AM
Subject: Percolating QC changes


Given a theoretical app with development, QC and production libraries. The devs send a new build to the QC library and continue work in the development library. 1-2 weeks later, the QC department returns their report, and code and data changes are required in the QC build.

Is there a best practice for percolating those changes to the development library?

TIA