RE: Percolating QC changes

I believe that the best way to handle source is to keep all production source in one place, and check it out when needed. When code is promoted, the source is deleted from the dev/QC environments. This keeps them from getting out of sync. For data, the shops I have worked at generally grabbed test data from production. Sometimes a regular refresh procedure captured a subset of production data for testing.

Mark Murphy
Atlas Data Systems
mmurphy@xxxxxxxxxxxxxxx


-----Justin Taylor <JUSTIN@xxxxxxxxxxxxx> wrote: -----
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
From: Justin Taylor <JUSTIN@xxxxxxxxxxxxx>
Date: 03/02/2017 02:05PM
Subject: RE: Percolating QC changes


The change needs to go thru the devs. The development library no longer matches the QC build, so you have to make the changes to the data & source for the QC build, and then build again. Almost certainly all of that must be duplicated in the development library. Source code can be merged, but data???



-----Original Message-----
From: Sam_L [mailto:lennon_s_j@xxxxxxxxxxx]
Sent: Thursday, March 02, 2017 12:55 PM
To: midrange-l@xxxxxxxxxxxx
Subject: Re: Percolating QC changes

So someone in QC is making changes? In my experience, an object had to go back to development to make the changes and QA was just a testing & review group.

However, if QA can make changes, you might want to look at Aldon Scompare/Harmonizer. Many years ago we used it to do a 3-way merge of vendor code with our changes when they updated their source. I believe it is still available (at least it was before Rocket bought Aldon.) Did a good job but you still had to review the code.

Sam