Back Migration plan

Document Sample
Back Migration plan Powered By Docstoc
					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
           Option 1
           (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.
           Option 2
           (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.)

                 [1]        QUAL                                                                                            ERP back migration from QUAL
                            > TEST

                 [2]        BETA                                                                                            ERP back migration from BETA
                            > QUAL
                            > TEST

                 [3]        PROD                                                                                            ERP back migration from PROD
                            > BETA
                            > QUAL
                            > TEST

                 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

                 [1]        TEST                                                          > TEST                            UTD activation from TEST

                 [2]        QUAL                           > QUAL                                                           UTD activation from QUAL
                                                           > TEST

                 [3]        QUAL                           > QUAL                                                           UTD back migration from QUAL
                            > TEST                         > TEST                         > TEST

                 [4]        BETA                                                                                            UTD back migration from BETA
                            > QUAL                         > QUAL
                            > TEST                         > TEST                         > TEST

                 [5]        PROD                                                                                            UTD back migration from PROD
                            > BETA
                            > 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
From:
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.

				
DOCUMENT INFO
Categories:
Tags:
Stats:
views:1
posted:7/30/2012
language:English
pages:3