Business rules (as of 4/30/12):
(1) UTD apps will be copied back to TEST and to QUAL as part of activation and back migration.
The minimal copying required for UTD is that logical TEST pPROD needs to be copied back to logical TEST pTEST and logical QUAL pPROD must be copied to logical QUAL
pQUAL. However, my thought is that logical TEST pQUAL should be copied as well to avoid creating competing applications in the QUAL environment.
Decision: We will move data through logical TEST pTEST and pQUAL and logical QUAL pQUAL only. (We can return to already present upper level structure later.)
The suggestion is that we sweep QUAL, BETA and PROD in physical TEST to eliminate any unneeded records. A possibility for later.
(2) Negotiable: ERP apps will be copied back to QUAL (only) as part of activation and back migration.
Under Option 2 for Apollo, copying ERP apps back to QUAL would be needed so that we can copy the Apollo owners to QUAL. If we control all from Apollo PROD,
we probably don't need to copy back ERP apps at all. (The worst that can happen is overwriting an existing testing application w/o removing Apollo owners from QUAL.)
Decision: We will not move ERP apps except through logical environments, since we will be using only Apollo PROD.
(3) Back migration will be from an environment through ALL lower environments. For example, there will be no back-migration from BETA that does not include TEST. (Agreed)
(4) Logical environments will always be filled in below the target. For example, if we are updating logical QUAL in physical QUAL, we will update logical TEST there as well. (Agreed.)
(5) Absolute URLs will be strictly copied from the relevant PROD logical environment as opposed to copying that data from the source logical/physical level, that is, TEST to TEST, etc.
Absolute URLs may include Primary-URL, Help-URL (ENVI) as well as Zoom-URL and Edit-URL
Question: We can eliminate access to TEST and QUAL or just disallow updates there based on constituents of an Apollo group. Which should it be?
Analysis for this is still needed; I don't know which is more difficult but think view-only access for developers would be preferable; otherwise they cannot see
apps are in TEST/QUAL for search/sitemap/breadcrumbs.
Decision: We will eliminate access for pTEST and pQUAL for most developers, those not on our dev group.
Question: Is it preferable to perform the environment copying during promotion and moderation rather than activation? And if activation, do they have to use multiple UI's?
Discussion is needed; I believe activation is preferable. However, back migration is not obviously related to the sitegen (and the choices that need to be made there),
so would there be two different choices and two different submits within activation?
Decision: We will perform the copying during activation rather than promotion/moderation. Julie & others will need to give us advice on details of the UI.
Question: If an Absolute URL is required but we are missing an environment, do we attempt to predict the URL if possible or do we fail on the basis of not having a value for the URL?
We might predict for ERP (which uses Help-URL only) but require/audit for UTD (Primary-URL as well as Triplets URLs). (It might be difficult to predict for URL's -- shouldn't that
be something that the developers provide rather than us guessing?)
Decision: Always copy through all levels of structure. If there is not a value for an absolute URL, don't create it. Leave it blank.
RULES FOR APOLLO
(A1-1) Use Apollo PROD for everything. (See separate file for more extensive discussion.)
(A1-2) Create applications in TEST and QUAL when needed, which will provide local ownership.
ADABAS switch may be beneficial re access/deletion. (To be discussed.)
(A1-3) When working with local ownership, add self to proposed Apollo under-development group temporarily; owned apps will be temporarily switched to local.
Note that the first search on the owned apps listing page is based on Apollo, thus subject to manipulation in TEST/QUAL.
(A2-1) Continue to use Apollo TEST for pTEST, Apollo QUAL for pQUAL, and Apollo PROD for pPROD.
(A2-2) Whenever logical TEST data is promoted to logical QUAL, Apollo data in pQUAL will be updated with the current owners.
(A2-3) For UTD apps, whenever logical TEST data is promoted to QUAL, Apollo data will also be updated in pTEST.
(A2-4) Apollo groups exist independently of our processes and cannot be modified by our processes; we can only audit for presence in QUAL (and TEST, if needed). (Discuss this.)
Independent Apollo groups, with the problem that they may not exist or may have different membership, are outside of our control and argue strongly for
changing our security to Apollo PROD.
(A2-5) Apollo changes coming from back migration / activation in PROD override any preexisting ones in TEST and QUAL.
Decided: We are using Option 1 (Apollo PROD only) without an ADABAS switch. Lookups will be to PROD EXCEPT with "My Owned Items", which will always be local.
Charts of possible actions
for ERP applications: The following copying operations will be available within each local physical environment: (Users will be concerned only with physical PROD.)
 QUAL ERP back migration from QUAL
 BETA ERP back migration from BETA
 PROD ERP back migration from PROD
Notes: All field values will be copied from the source logical environment EXCEPT Primary-URL (ENVI), Zoom-URL (TRIP), and Edit-URL (TRIP), which will remain
with the current value in each logical environment.
for UTD applications: The following copying operations will be available across each physical environment:
pPROD pQUAL pTEST
 TEST > TEST UTD activation from TEST
 QUAL > QUAL UTD activation from QUAL
 QUAL > QUAL UTD back migration from QUAL
> TEST > TEST > TEST
 BETA UTD back migration from BETA
> QUAL > QUAL
> TEST > TEST > TEST
 PROD UTD back migration from PROD
> QUAL > QUAL
> TEST > TEST > TEST
Notes: All fields will be copied from the source logical environment in PROD except for Help-URL (ENVI).
The chart below represents the old plan and is *out of date*. We will populate all logical environments in PROD as well as TEST in pTEST and TEST/QUAL in pQUAL for UTD items only.
Back migration To: PPROD LPROD PPROD LBETA PPROD LQUAL PPROD LTEST PQUAL LPROD PQUAL LBETA PQUAL LQUAL PQUAL LTEST PTEST LPROD PTEST LBETA PTEST LQUAL PTEST LTEST
PTEST LTEST DNA
PTEST LQUAL DNA Yes
PTEST LBETA DNA Yes Yes
PTEST LPROD DNA Yes Yes Yes
PQUAL LTEST DNA no no no UTD only
PQUAL LQUAL DNA Yes no no UTD only UTD only
PQUAL LBETA DNA Yes Yes no UTD only UTD only UTD only
PQUAL LPROD DNA Yes Yes Yes UTD only UTD only UTD only UTD only
PPROD LTEST DNA no no no Yes no no no UTD only
PPROD LQUAL DNA Yes no no Yes Yes no no UTD only UTD only
PPROD LBETA DNA Yes Yes no Yes Yes Yes no UTD only UTD only UTD only
PPROD LPROD DNA Yes Yes Yes Yes Yes Yes Yes UTD only UTD only UTD only UTD only
***OLD CONCLUSIONS ARE BELOW:***
Questions & considerations:
(1) How in-sync do we need to keep PTEST and PQUAL? If someone overwrites a preexisting app in TEST and QUAL, should we try to maintain the upper levels of TEST/QUAL in any way? (No.)
(2) Do we care about Apollo ownership in TEST and QUAL? That is, do we have to copy current owner records or do we just ignore that?
(Recommendation is that we overwrite TEST and QUAL Apollo ownership with our UTD steward group.)
(3) How will we care about preexisting information at an upper level? (We will not affect it in any way. If it exists, we'll leave it alone. We won't attempt to reset it if it belongs to a TEST app.)
(4) Will we care about preexisting authorizations? (Yes. We will overwrite with a common group authorization.)
(5) What will need to be written?
(a) We can simplify the promotion update module, because it will only need to take into account 3 levels of structure.
(b) We will need to write a module that overwrites Apollo authorizations and adds the group authorization for UTD stewards.