

Best Practice Implementation › How to Perform the Best Practice Implementation › BPI Software Inventory Lifecycle › BPI Environment and Stages
BPI Environment and Stages
Each lifecycle defines the movement of software inventory from environment-stage to environment-stage until the end of the lifecycle. Each environment has two stages and each environment-stage represents a library level. To support this structure, the data set naming convention uses qualifiers to identify each environment and each stage. Details follow about each environment.
- Development (DEV) environment— This environment has two stages that allow you to maintain two versions of an element. You can use Stage 2 as a location for elements that are considered complete or as a temporary holding place for confirmed changes, while you re-edit the element in Stage 1. Stage 2 also provides another location useful for merging changes together with those that have been promoted to QAS or PRD. Another benefit of two development stages is to be able to test with different compiler parameters at Stage 1 verses Stage 2. For example, Stage 1 could be set to test compile options and Stage 2 could be set to production compile options. The last compile, before moving up the lifecycle, is always done at DEV Stage 2.
- Quality Assurance (QAS) environment— This environment is used to perform many different types of testing. Stage 1 provides a common integration stage. Although useful, to reduce the number of stages an element must pass during the path to production, Stage 1 of the QAS environment is not used in the BPI delivered lifecycle. Stage 2 would be used to make sure the applications are system tested and ready for production.
- Production (PRD) environment— This environment represents the production code. Stage 1 of the PRD environment is not used in the BPI delivered lifecycle. Stage 2 is used for the storage of the production source. The PRD environment should be package protected.
- Unclaimed (UNCLMED) environment— This environment is used to store elements that could not be classified in the standard inventory structure (systems, subsystems, and so on.). Only the second stage is used for this environment. This environment is intended to be a holding area for elements whose use and purpose is unknown. This may be common in conversion situations, when converting from a different source control management application to CA Endevor SCM. The UNCLMED environment stores only the source and has only one system and subsystem. Its purpose is a temporary holding position for those elements not identified with a system during the implementation (or conversion) process. If an element is found missing after the CA Endevor SCM Implementation is complete, you can look in the UNCLMED environment to see if the element is there. You can then transfer that element from UNCLMED to the appropriate system and subsystem. After elements in UNCLMED have been identified and transferred into the correct system-subsystem, the version in UNCLMED should be deleted. The final goal should be to discontinue the UNCLMED environment in time.
- Administrator (ADMIN) environment— This environment is separate from the DEV to QAS to PRD lifecycle, and is reserved for the role of the CA Endevor SCM administrator. The CA Endevor SCM administrator has different security requirements than the development and testing teams. The separate security rules for the administrator role are easier to maintain if in a separate ADMIN environment. The ADMIN environment’s data sets begin with a different high level qualifier, while the remaining environments (DEV, QAS, PRD, EMER, UNCLMED, and ARCHIVE) all use the application high level qualifier. Stage 2 of the ADMIN environment hosts the CA Endevor SCM Configuration Tables that are used to define the site’s infrastructure and default options, as well as the Endevor processors which are used to process all the elements for each system in the standard DEV to QAS to PRD lifecycle. Stage 1 of the ADMIN environment provides an area for the administrator to make changes as needed to any of the tables or processors maintained within the ADMIN environment. Stage 2 only stores the elements specific to CA Endevor SCM administrators. Sites can then use packages to promote their changes from Stage 1 to Stage 2, allowing for a back-out if needed.
- Emergency (EMER) environment— This environment is also separate from the standard lifecycle. This environment is used for coding fixes that need to be put in immediately. Stage 1 of the EMER environment serves as the place where the code changes are to be made. Stage 2 of EMER is package protected and must be included in the production JCL STEPLIB concatenation. An emergency package needs to be created to promote elements from Stage 1 to Stage 2. An approval needs to be made by those that were assigned in the approver group(s). An emergency approver group must be given the authority to approve emergency packages. This is required to prevent unapproved changes being picked up by production. EMER maps to the PRD environment for ease of making changes to programs and components. It is probable that emergency changes promoted to EMER Stage 2 will afterwards be transferred to the DEV environment (via the TRANSFER action) and then promoted through the typical lifecycle and testing procedures before being permanently moved to production. The EMER environment contains the same types, systems, and subsystems as the PRD environment. The EMER Stage 2 loadlib should be concatenated before the production stage 2 loadlib, to pick up any emergency changes.
- The Archive (ARCHIVE) environment— This environment is used to store elements that are deleted from the PRD environment, but a site still wants to maintain a copy of for auditing or history purposes. The ARCHIVE environment utilizes only the second stage of this environment (Stage 2). Elements need to be transferred there via the TRANSFER action or via a PACKAGE with TRANSFER action SCL. It is a stand-alone environment. The ARCHIVE environment contains all the types, systems, and subsystems of the PRD environment.
Copyright © 2014 CA Technologies.
All rights reserved.
 
|
|