RE: Percolating QC changes

While a change is in QC, it has it's source there, so I would check out the objects from QC, make the change and promote back to QC. so a given object may have source in multiple places depending on what changes are in process.

Production - this is always the live source, never changed.
QC - this environment contains only objects associated with changes in QC
DEV - this environment only contains objects checked out for development.

Each environment here will have it's own database which persists after promotion. Data objects, unlike program objects are not removed, but the source for those data objects is removed as it is promoted up the chain. If you need the source back, check it out, and recreate.

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/03/2017 12:12PM
Subject: RE: Percolating QC changes


If you keep all of your source in one place, how do you make changes to a QC build from 1-2 weeks ago?

I'm not thinking of user data, but app data that's deployed as part of a given build.




-----Original Message-----
From: Mark Murphy/STAR BASE Consulting Inc. [mailto:mmurphy@xxxxxxxxxxxxxxx]
Sent: Friday, March 03, 2017 8:50 AM
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
Subject: 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