Agile and Concurrent Development Configuration

Sandbox Subsystems facilitates concurrent development, which supports Agile development
CA Endevor 18.1
Sandbox Subsystems facilitates concurrent development, which supports Agile development.
Agile Development Using Code Branches
The Agile software development methodology enables rapid and flexible response to change. Agile often involves concurrent development and requires that the application code base (trunk) always exists in a buildable state. To facilitate agile development, users make code changes in code branches. With
CA Endevor
, code branches are implemented using
sandbox Subsystems (sandboxes)
. Each sandbox serves as a branch, that is, a separate development work area that maps to the trunk. This development method is referred to as the
CA Endevor
sandbox development method for concurrent development.
After the user creates a sandbox for a project, they copy the Elements that require changes into that sandbox. When the Elements get generated, the generate processor automatically uses (concatenates) the unchanged current source code from the trunk. The generate processor creates an executable form of the Element, together with any associated outputs (such as listings). This process keeps the application trunk stable.
In the following graphic, three branches (development sandboxes) map to an application trunk to support concurrent development.
agile1.png
Many branches can exist simultaneously to support different users working on various fixes and enhancements. A branch can also serve as a private work area for a particular user, instead of for a particular project.
In the following graphic, numerous branches exist simultaneously, because users added branches as needed. Changes from any branch can be promoted to the trunk after they have been successfully tested.
agile2.png
Generally, branches are temporary work areas. After the user completes unit tests and regression tests on the changes in a branch, the user can merge the changes into the code trunk for final regression tests and then promote the changes to production. At this point, the branch is no longer needed and can be deleted with its outputs.
Agile development with sandbox Subsystems (sandbox development) involves the following terms:
Trunk
The trunk is the code base for an application. In
CA Endevor
, the trunk is typically defined as a System. This System can have one or more Subsystems, depending on the complexity of the application.
Branch
A branch is a sandbox Subsystem that contains Elements that must be changed, usually for a particular project. Usually, branches are only in a development Environment, but can also be in other Environments. A branch is defined as a sandbox Subsystem that maps to the trunk Subsystem that contains the application base code. This mapping allows generate processors to reference Element members that are located within a development sandbox and also reference Elements that reside higher in the lifecycle.
Sandbox Subsystem (sandbox)
A sandbox Subsystem (sandbox) is a Subsystem that provides a separate development work area that maps to the code trunk. Each sandbox Subsystem is a branch off the code trunk of the application that the user plans to change. Users can add branches as needed. Multiple branches can exist simultaneously. A development branch can be private or shared. For example, a branch could serve as a private work area for one user, for an individual fix or enhancement, or for a project that has one or more users working in the same branch on the same project.
Type Sandbox
The Type Sandbox is an Element Type that the
CA Endevor
administrator defines to include a sandbox processor group that is composed of the delivered sandbox generate and delete processors. The Type Sandbox enables users to create sandbox Subsystems (branches) easily. The same Type Sandbox is used to create all branches, regardless of the application that the branch modifies. Therefore the administrator only needs to define the Type Sandbox once. The administrator can decide what to name this Type. However, this article assumes that the Type name is "Sandbox."
Element of Type Sandbox (sandbox Element)
The purpose of the sandbox Element is to provide a mechanism to create a sandbox Subsystem (branch). A sandbox Element is created when a user creates an Element with a Type specification of Sandbox. When creating this Element, the user also specifies that the Element is to be created in Stage 1 of the Development Environment in the Subsystem for the application the user plans to change. When the Element is created, the sandbox generate processor automatically runs and creates a sandbox Subsystem and its required data sets. The sandbox Subsystem maps to the trunk Subsystem for the application the user plans to change.
Sandbox Generate processor
The processor that runs when a user creates a sandbox Element. This processor creates a sandbox Subsystem and its required data sets as follows. The processor submits a batch admin job that defines a sandbox Subsystem (branch) that maps to the Subsystem (trunk) where the user added the sandbox Element. The sandbox Subsystem name is the same as the name that the user specified for the sandbox Element. The processor defines all the data sets that could be needed for this Subsystem based on the Types defined to the System. The Type definitions must use
CA Endevor
symbolic variables to define the data sets. The symbols resolve to different data sets names based on the location of the sandbox Subsystem.
Sandbox Delete processor
The processor that runs when a user deletes a sandbox Element. The processor also deletes the sandbox Subsystem and data sets that the sandbox generate processor created for this sandbox Element.
To implement sandbox development, certain requirements and recommendations apply. For more information, see Configure
CA Endevor
for Concurrent Development
.
Modify an Application in Production
This use case example provides an overview of the concurrent development process using sandbox Subsystems. For this example, the following assumptions apply:
Change request
The following changes are requested to the Payroll application (a COBOL application) that is currently in production. A different user has been assigned to work on each modification.
  • Change the payroll deduction for federal tax.
  • Change the payroll deduction for state tax.
CA Endevor
configuration
Assume the product has been configured as follows:
  • The
    CA Endevor
    administrator has created a Type Sandbox. Also, the data sets defined in all the Type definitions and referenced in the Processors use the inventory location symbols.
  • The software development lifecycle configuration and the inventory classification for the Payroll application are shown in the following graphic:
Agile_example_1.png
  • The lifecycle includes the following Environments and Stages in the map.
    • Development Environment, with the following Stages:
      • Unit Test Stage— In this Stage, the user changes Elements and runs unit tests. Generally, these tests verify whether the change has had the intended effect.
      • Unit Test Complete Stage— After all unit tests run successfully, Elements are moved to this Stage for QA regression testing. Generally, regression testing determines whether the changes have introduced new faults, that is, adversely affected other parts of the software application.
    • QA Environment, with the following Stage:
      • QA Certification Stage— In this Stage, the same QA regression tests are rerun that were run in the Development Stage Unit Test. Rerunning the tests successfully verifies that no problems are caused by any changed Elements that were moved to the trunk from another sandbox after this sandbox was tested, but before it was moved to the trunk.
    • Production Environment, with the following Stage:
      • Production Stage— Your applications can be run from this location or deployed to another location for execution.
  • The Subsystems are mapped so that Move actions move the software inventory from Subsystem to Subsystem as shown by the arrows in the graphic.
  • The Payroll application is classified as a Subsystem in the Finance System and is located in the Production Stage. The administrator has defined the Payroll Subsystem in
    all
    the Stages in the software development lifecycle. Generally, Elements exist outside of the Production Stage only if they are being actively modified.
  • Approver groups are defined for the QA Certification Stage and Production Stage. Therefore, to move Elements into these Stages, Packages must be used and the Packages must be approved before the Move actions can be executed.
The logical configuration of a lifecycle is supported by data sets that are defined according to the location of the software inventory in the lifecycle. The recommended common data set naming convention is implemented using the
CA Endevor
inventory location symbols: &C1SYS for the System; &C1SUB for the Subsystem; &C1ENV(1,1) for the Environment; and &C1STG# for the Stage number. For example, the data set name for the COBOL base library for the Payroll application in Stage 1 of the Development Environment would resolve to:
upfx
.FINANCE.PAYROLL.D1.COBOL
To make the requested changes, the users perform these steps:
The following graphic summarizes the steps for one user working on one project. However, several users could be working on different projects simultaneously. In this use case, two users are working concurrently. One user works on the modification for the federal tax deduction, while the other user works on the modification for the state tax deduction. This use case can be performed using Quick Edit or the “classic” ISPF panel UI. However, the steps in this example refer to Quick Edit. The exact commands entered by the user depend on which interface they are using.
agile steps new6.png
Follow these steps:
  1. Create and generate a sandbox Element in Development Stage 1 in the Subsystem (trunk) for the application that you want to modify.  In Quick Edit, use the Create Element action to create the sandbox Element and specify the inventory location where you want the Element created.
    In this example, each user creates a sandbox Element for the change that is assigned to them as follows:
    • The user who is assigned to the federal tax change, creates an Element named
      FedTax
      in the Payroll Subsystem in Stage 1 of the Development Environment.
    • The user who is assigned to the state tax change, creates an Element named
      StateTax
      in the Payroll Subsystem in Stage 1 of the Development Environment.
    In Quick Edit, the generate processor runs when the Element is saved. In this example, when each user saves the sandbox Element they created, the generate processor executes for each sandbox Element, with the following results:
    • Two sandbox Subsystems are added to the System where the Payroll Subsystem is located. The name that the user specified for the Element is used to name the Subsystem. Therefore, one of these Subsystems is named
      FedTax
      and the other is named
      StateTax
      . Both sandboxes are branches of the Payroll application base code (trunk). The branches map into the trunk (Payroll Subsystem) in the QA Certification Stage in the QA Turnover Environment.
    • The necessary base and output data sets are defined for each sandbox Subsystem. The sandbox generate processor uses the
      CA Endevor
      inventory location symbols, which resolve to different data sets names based on the location of the sandbox Subsystem:
      upfx
      . &C1SYS..&C1SUB..&C1ENV(1,1).,&C1STG#.
      &C1SYS
      Indicates the System name
      &C1SUB
      Indicates the Subsystem name
      &C1ENV(1,1)
      Indicates the first character of the Environment name
      &C1STG#
      Indicates the Stage number
      In this example, the high-level qualifier (upfx) is set to "NDV". The data sets are defined for the Finance System, Payroll Subsystem in Stage 1 of the Development Environment as follows:
      • Base libraries
        The generate processor defines a base library for every Type that is defined to the System inventory location. Multiple libraries can be defined, because multiple Types can be defined to a System. The sandbox generate processor uses the following definition to define the base libraries, where the symbol &C1TYPE resolves to a Type name.
        upfx
        . &C1SYS..&C1SUB..&C1ENV(1,1).,&C1STG#..&C1TYPE
        If the Type is COBOL, the following base library is defined for Elements of Type COBOL:
        NDV.FINANCE.FEDTAX.D1.COBOL
      • Processor output libraries
        The generate processor defines the processor output libraries using the following definitions:
        upfx
        .&C1SYS..&C1SUB..&C1ENV(1,1).,&C1STG#..OBJLIB
        upfx
        .&C1SYS..&C1SUB..&C1ENV(1,1).,&C1STG#..LOADLIB
        upfx
        .&C1SYS..&C1SUB..&C1ENV(1,1).,&C1STG#..LISTLIB
        These definitions resolve to the following data sets:
        NDV.FINANCE.FEDTAX.D1.OBJLIB
        NDV.FINANCE.FEDTAX.D1.LOADLIB
        NDV.FINANCE.FEDTAX.D1.LISTLIB
      For a table of all the base libraries and output data sets created in this example, see Data Sets Created in this Example.
  2. Add or modify Elements in the sandbox
    using the Quick Edit Create or Edit Element actions
    .
    The following graphic shows the results of step 1 where the users added the new code branches FedTax Subsystem and StateTax Subsystem. The straight arrows between the Stages indicate how the Stages are mapped to move the software inventory from Subsystem to Subsystem. The results of step 2 are indicated by the curved dotted arrows from the Production Environment to the Development Environment. These arrows show that the users used the Edit command in Quick Edit to copy Elements from the trunk in the Production Environment to the branch Subsystems in the Development Environment.
    Agile_example_QE.png
    If the Element that you want to create or edit is already signed out to someone else, you cannot work on it unless you are authorized (have security permission) to use the Override Signout option. In Quick Edit, when you enter an Edit or Create comment, a messages informs you if the Element is already signed out.
    • If the Element is already signed out, confer with the owner of the Element before overriding the signout status of the Element.
    • If you want to sign out the Element, you must specify the Override Signout option and re-enter the Edit or Create request.
      • If you are authorized to use the Override Signout option, the request is processed.
      • If you are not authorized, an error message is returned.
    The Override Signout option has an important role in a concurrent development scenario. An Element's Signout status helps to control who can work on an Element, which helps prevent unwanted regressed changes from being saved to the trunk.  The Override Signout option lets users work on copies of the same Element in different sandboxes at the same time. This is concurrent development. In this scenario, when a user attempts to move a copy of an Element to the trunk after another copy of that Element has been saved to the trunk, any conflicting changes to the Element must be resolved. For more information, see Resolve Conflicting Changes.
    By default, in Quick Edit, the generate processor executes each time that you end an Edit session saving the file. Executing the generate processor that is defined for the Element Type creates an executable of the Element and other associated outputs. The generate processor concatenates the unchanged current source code from the code base (trunk).
    In this example, if an Element of Type COBOL named TAXTBL01 located in the FEDTAX Subsystem in Stage 1 of the Development Environment is generated, the data set member TAXTBL01 would be created for the following data sets:
    • NDV.FINANCE.FEDTAX.D1.COBOL (base library)
    • NDV.FINANCE.FEDTAX.D1.OBJLIB (processor output)
    • NDV.FINANCE.FEDTAX.D1.LOADLIB (processor output)
    • NDV.FINANCE.FEDTAX.D1.LISTLIB (processor output)
  3. Test your changes
    . Run unit tests to verify that the changes have the intended effect. Then, move the Elements to the Unit Test Complete Stage for QA regression testing. Generally, regression testing determines whether the changes have introduced new faults, that is, adversely affected other parts of the software application.
  4. Create a Promotion Package to validate, approve, and move the Element changes
    . In this example, each user creates a Promotion Package to move their own changes from the Unit Test Complete Stage to the QA Certification Stage in the QA Environment. The Package must be Cast, Approved (if required), and Executed to move the Elements. The user performs the following actions:
    1. Creates a Package
      that contains Move actions to move the changed or new Elements to the next Stage in the lifecycle, the QA Certification Stage.
    2. Casts the Package.
      CA Endevor
      processes the Cast request as follows:
      1. Performs a synchronization (sync) check
        to ensure that all the Elements in the sandbox will not regress changes that may exist at a higher location in the software lifecycle (QA or Production). If this check fails, it is because a concurrent development scenario is detected.
        For example, assume that copy A of TAXTBL01 was already moved to the QA Certification Stage and that another user attempted to move copy B of TAXTBL01 to the same Stage. The sync check would prevent copy B from being moved to this Stage, if copy B was created from the original TAXTBL01 before it was changed by copy A. In this case, changes are required to synchronize the Elements. These changes are made in the sandbox. After the user has consolidated the changes, the user edits the Package SCL to add the Sync option to the Move action for the Element that failed the sync check. The Sync option allows the Move action to execute. Then, the user restarts the Package to continue processing.
        For more information about resolving conflicting changes, see Resolve Conflicting Changes.
      2. Performs an Element component validation check
        to ensure the Elements that were generated in the sandbox were successfully generated and built using the most recent iterations of their input components (that is, dependencies, such as copybooks, macros, and so on). If this check fails, the user must resolve the issues described in the error messages by making the necessary changes to the sandbox Elements in error. Then the user restarts the Package to continue processing.
      3. Locks the Elements
        in the sandbox to prevent subsequent changes.
        CA Endevor
        can also lock the Elements at the target location to prevent other users from making changes to Elements that interfere with the execution of the Package. The administrator sets the lock functionality in the Optional Features table, ENCOPTBL using the PKG_ELEMENT_LOCK option.
      4. Determines if approval is required
        before the Package can be executed.
        CA Endevor
        alerts the Approvers by email, if configured to do so.
      When Cast processing completes successfully, the Package passes to the Approval state if approval is required.
      • If approval is
        not
        required, the Package can now be executed as it is automatically put into the approved state.
      • If approval is required, the approvers are notified. When approved, the Package can be executed to move the Elements to the next Stage.
        We recommend that most QA testing be done at the sandbox level. Resolving issues in sandboxes reduces the amount of time that Elements reside in the QA Environment and avoids bottleneck situations in the QA Environment. Some tests should be rerun in the code trunk in the QA Certification Stage in the QA Environment. Rerunning the tests successfully verifies that no problems are caused by any changed Elements that were moved to the trunk from another sandbox after this sandbox was tested but before it was moved to the trunk.
  5. Execute the Package to move the Elements to the trunk in the QA Certification Stage
    in the QA Environment. Perform final quality assurance testing in this Stage. After testing is successfully completed, the changed Elements are ready to move to Production.  If approvals are required, approvers are notified and the Package must be approved before it can be executed.
  6. Execute the Package to move the Elements to Production
    . After the Package is executed and the changes have been successfully moved to production, you can delete the sandbox Element that was used to create the sandbox Subsystem. The Delete action runs the sandbox Delete processor, which has the following effects:
    1. Deletes the sandbox Element. If Elements still exist in the sandbox Subsystem, the delete fails. If the sandbox contains any Elements, the user must manually remove them before attempting to delete the sandbox Element again.
    2. Deletes the sandbox Subsystem.
    3. Deletes the data sets associated to that sandbox Subsystem.
      The
      CA Endevor
      administrator can configure the product so that when a Package is successfully promoted to production, the sandbox Delete processor automatically executes.
Data Sets Created in this Example
The following tables list the data sets that exist for the code trunk and the data sets created in step 1 for the sandboxes. The sandboxes and their data sets exist only in the Development Environment. (The sandbox libraries are temporary, because they are deleted by the sandbox delete processor when the user chooses to delete the sandbox Subsystem.) The data set naming convention is implemented using
CA Endevor
inventory location symbols: &C1SYS for the System; &C1SUB for the Subsystem; &C1ENV(1,1) for the Environment; and &C1STG# for the Stage number.
Base Libraries—
The following table shows the data sets names for the base libraries that are defined for the Subsystems in this example. The first row shows the data sets that exist for the PAYROLL Subsystem. These were created when the administrator configured the lifecycle to define the Payroll Subsystem in all the Stages in the lifecycle. The last two rows show the base libraries that were created by the sandbox generate processor for the new sandbox Subsystems FedTax and StateTax.  A base library is created for each Type that is defined to the PAYROLL Subsystem (code trunk) for which the sandbox Subsystems (branches) are created.
The sandbox generate processor also defines both the FedTax and StateTax sandbox Subsystems in the last stage of the development Environment to map to the Payroll Subsystem in the QA Environment, Stage 2. So, each sandbox Subsystem library in the Development Environment, Stage 2 maps to a corresponding Payroll library in the QA Environment, Stage 2. For example, both NDV.FINANCE.FedTax.D2.COBOL and NDV.FINANCE.StateTax.D2.COBOL map to NDV.FINANCE.PAYROLL.Q1.COBOL.
Subsystem
Development Environment, Stage 1
Development Environment, Stage 2
QA Environment, Stage 2
PAYROLL (code trunk)
NDV.FINANCE.PAYROLL.D1.COBOL
NDV.FINANCE.PAYROLL.D1.COPYBOOK
NDV.FINANCE.PAYROLL.D1.ASMMAC
NDV.FINANCE.PAYROLL.D1.CICSMAP
NDV.FINANCE.PAYROLL.D1.BIND
NDV.FINANCE.PAYROLL.D2.COBOL
NDV.FINANCE.PAYROLL.D2.COPYBOOK
NDV.FINANCE.PAYROLL.D2.ASMMAC
NDV.FINANCE.PAYROLL.D2.CICSMAP
NDV.FINANCE.PAYROLL.D2.BIND
NDV.FINANCE.PAYROLL.Q1.COBOL
NDV.FINANCE.PAYROLL.Q1.COPYBOOK
NDV.FINANCE.PAYROLL.Q1.ASMMAC
NDV.FINANCE.PAYROLL.Q1.CICSMAP
NDV.FINANCE.PAYROLL.Q1.BIND
Fed Tax sandbox Subsystem (code branch)
NDV.FINANCE.FedTax.D1.COBOL
NDV.FINANCE.FedTax.D1.COPYBOOK
NDV.FINANCE.FedTax.D1.ASMMAC
NDV.FINANCE.FedTax.D1.CICSMAP
NDV.FINANCE.FedTax.D1.BIND
NDV.FINANCE.FedTax.D2.COBOL
NDV.FINANCE.FedTax.D2.COPYBOOK
NDV.FINANCE.FedTax.D2.ASMMAC
NDV.FINANCE.FedTax.D2.CICSMAP
NDV.FINANCE.FedTax.D2.BIND
Not Applicable
State Tax sandbox Subsystem (code branch)
NDV.FINANCE.StateTax.D1.COBOL
NDV.FINANCE.StateTax.D1.COPYBOOK
NDV.FINANCE.StateTax.D1.ASMMAC
NDV.FINANCE.StateTax.D1.CICSMAP
NDV.FINANCE.StateTax.D1.BIND
NDV.FINANCE.StateTax.D2.COBOL
NDV.FINANCE.StateTax.D2.COPYBOOK
NDV.FINANCE.StateTax.D2.ASMMAC
NDV.FINANCE.StateTax.D2.CICSMAP
NDV.FINANCE.StateTax.D2.BIND
Not Applicable
Processor Output Libraries—
The following table shows the data sets names for the processor output libraries that are defined for the Subsystems in this example. The first row shows the data sets that exist for the PAYROLL Subsystem. These were created when the administrator configured the lifecycle to define the Payroll Subsystem in all the Stages in the lifecycle.The last two rows show the processor output libraries that were created by the sandbox generate processor for the new sandbox Subsystems FedTax and StateTax.  A processor output library is created for the load library, object library, and the listing library.
The sandbox generate processor also defines both the FedTax and StateTax sandbox Subsystems in the last stage of the development Environment to map to the Payroll Subsystem in the QA Environment, Stage 2. So, each sandbox Subsystem library in the Development Environment, Stage 2 maps to a corresponding Payroll library in the QA Environment, Stage 2. Both NDV.FINANCE.FedTax.D2.LOADLIB and NDV.FINANCE.StateTax.D2.LOADLIB map to NDV.FINANCE.PAYROLL.Q1.LOADLIB.
Subsystem
Development Environment, Stage 1
Development Environment, Stage 2
QA Environment, Stage 2
PAYROLL (code trunk)
NDV.FINANCE.PAYROLL.D1.LOADLIB
NDV.FINANCE.PAYROLL.D1.OBJLIB
NDV.FINANCE.PAYROLL.D1.LISTLIB
NDV.FINANCE.PAYROLL.D2.LOADLIB
NDV.FINANCE.PAYROLL.D2.OBJLIB
NDV.FINANCE.PAYROLL.D2.LISTLIB
NDV.FINANCE.PAYROLL.Q1.LOADLIB
NDV.FINANCE.PAYROLL.Q1.OBJLIB
NDV.FINANCE.PAYROLL.Q1.LISTLIB
Fed Tax sandbox Subsystem (code branch)
NDV.FINANCE.FedTax.D1.LOADLIB
NDV.FINANCE.FedTax.D1.OBJLIB
NDV.FINANCE.FedTax.D1.LISTLIB
NDV.FINANCE.FedTax.D1.LOADLIB
NDV.FINANCE.FedTax.D1.OBJLIB
NDV.FINANCE.FedTax.D1.LISTLIB
Not Applicable
State Tax sandbox Subsystem (code branch)
NDV.FINANCE.StateTax.D1.LOADLIB
NDV.FINANCE.StateTax.D1.OBJLIB
NDV.FINANCE.StateTax.D1.LISTLIB
NDV.FINANCE.StateTax.D1.LOADLIB
NDV.FINANCE.StateTax.D1.OBJLIB
NDV.FINANCE.StateTax.D1.LISTLIB
Not Applicable
Resolve Conflicting Changes
Cast Package processing includes a synchronization (sync) check. The sync check fails if the target Element in the trunk was updated after the user made the copy of the Element that they are attempting to move. If modification to the Elements are required to appropriately combine the changes, these changes are made in the sandbox.
A concurrent development scenario is when more than one user is working on a copy of the same Element, but in different sandboxes. The purpose of the sync check is to ensure that all the Elements in the sandboxes will not regress changes that may exist at a higher location in the software lifecycle (QA or Production).
For example, suppose the following concurrent development scenario takes place in this order:
  1. Element TAXTBL01 already resides in the trunk.
  2. Working in Quick Edit, user A enters the Edit command to make a copy (copy A) of TAXTBL01 and copies it to a sandbox. Copy A is signed out to user A. User A edits copy A.
  3. Working in Quick Edit, user B enters the Edit command with the Override Signout option, to make a copy (copy B) TAXTBL01 and copies it to another sandbox. Copy B is signed out to user B. User B edits copy B.
  4. After finishing the edits, user A moves copy A to the trunk, so that Element TAXTBL01 now includes the changes made by user A.
  5. After finishing the edits, when user B attempts to move copy B to the trunk using a Package, the sync check on the Cast Package action detects that TAXTBL01 has been updated after copy B was created. The check fails.
To resolve conflicting changes, the user can choose to use one of the following methods. The appropriate method depends on the complexity of the conflicting changes.
  1. Delete copy A and recopy the current TAXTBL01 to the sandbox and make the changes to the new copy. This method is recommended for simple conflicting changes.
  2. Use the Parallel Development option (PDM) to assist in merging the changes. Recommended for complex conflicting changes.
  3. Manually change and use the sync option on the move action to override the out-of-sync check performed by the move action.
  4. Resolve the source conflict outside
    CA Endevor
    and use the Synchronize option in the Update action to reorganize the Element levels and resolve the out-of-sync condition.
  5. Manually resolve the source conflict and use the "SY - sync in place" command in Quick Edit to reorganize the Element levels and resolve the out-of-sync condition.
  6. Ignore the conflicts with the intention to regress the changes and use the sync option on the Move action to override the out-of-sync check performed by the Move action.
After the user has corrected the changes, the user edits the Package to add the Sync option to the Move action for the Element that failed the sync check. The Sync option allows the Move action to execute.
Configure
CA Endevor
for Concurrent Development
As a
CA Endevor
administrator, you can configure
CA Endevor
to enable users to perform concurrent development using sandbox Subsystems. To support concurrent development using sandbox Subsystems, the following requirements and recommendations apply.
Requirements
  • Type Sandbox
    — To enable users to create sandbox Subsystems (branches) easily, the administrator creates a
    Type Sandbox
    . This Type automates the process of creating sandbox Subsystems. The Type Sandbox includes a processor group, which consists of the delivered sandbox generate and sandbox delete processors.  When the user creates an Element of Type Sandbox, the sandbox generate processor creates a sandbox Subsystem. The same Type Sandbox can be used to create all branches, regardless of the application. Therefore the administrator only needs to define the Type Sandbox once. The administrator can decide what to name this Type, however this article assumes that the Type name is "Sandbox." For more information, see the "Create a Type Sandbox" section of this article.
  • Common data set naming convention
    — The data set naming convention that is implemented using
    CA Endevor
    inventory location symbols (&C1SYS for the System; &C1SUB for the Subsystem; &C1ENV(1,1) for the Environment; and &C1STG# for the Stage number). This requirement enables the same processors to run in any sandbox. For Sandbox Subsystems created using the Type Sandbox to function without modification,
    CA Endevor
    must be configured as follows:
    • Element Type definitions must use the inventory location symbols in library data set names. Using symbolic variables allows the same Type definition to point to different libraries based on the inventory classification (location) of the Element.
    • Processors must reference data sets using the inventory location symbols. When a processor runs against an Element, the symbols in the data set references are replaced with the inventory location of the Element. This substitution enables the same processors to point to the appropriate data sets for all locations including sandboxes.
Recommendations
  • To facilitate data security, the following features are highly recommended:
    • Alternate ID
      — The Alternate ID ensures that users without privileged authorization must perform their updates using
      CA Endevor
      , which tracks all changes. When the Alternate ID is implemented, only users with privileged authorization (such as administrators or systems programmers) can update data sets outside the control of
      CA Endevor
      (usually for purposes of regular file maintenance).
    • Approver groups— Define approver groups for the QA Certification Stage and the Production Stages so that Package approval is required before a Package of Move actions can move Elements into these Stages. If one or more approver groups are associated with the Environment, Stage (the target location if this is a Move action) specified in a Package, then the Package must be reviewed and approved before it can be executed. To be approved, the Package must be accepted by all of the required approvers, be accepted by a quorum of approvers, and not be denied by any approver.
  • To facilitate the concurrent development process, users should be authorized to take advantage of the following options. Verify that your External Security Interface (ESI) settings allow the appropriate users to access these options.
    • Promotion Packages
      — Promotion Packages are recommended, because they provide automated functionality that makes them easier to use than ordinary Packages.
      A Promotion Package is a Package of Move actions that automatically promote the Package contents along the lifecycle map until they reach the final Stage. A promotion Package consists of Move actions only and the from Environment and Stage location for all Move actions must be the same. Although you can reuse a promotion Package, you still must approve the Package between executions, if approval is required, but you do not have to reset the Package, manually edit the SCL to modify the move action location specifications, or re-cast the Package. A history of the Promotion Package is retained. 
    • Override Signout— This option lets users make copies of Elements that are already signed out to another user.
    • Sync Option— This option specified on Move actions lets users move Elements after they fail a sync test on the Package Cast action. This enables users to move a copy of an Element to the trunk to override changes previously made to the trunk by another copy of that Element. Users should be cautioned to use the Sync option only after they integrate conflicting changes so that moving the Element does not regress changes.
  • To facilitate the concurrent development process, the administrator should set an concurrent development policy that includes the following standards:
    • Decide on a policy for using development branches. For example, do you want your users to use private or shared branches, or a combination of both, and what naming convention should be used? Any valid Subsystem name can be used to name a branch. If a branch is to be used by a particular user, then using the user's user ID as the name can help avoid confusion. If multiple users are sharing a branch, then name the branch according to the project, feature, or Change Control Identifier (CCID) that the group is working on.
    • Instruct your users to use the Type Sandbox to create a branch before working on a code change and to follow your policy regarding private and public branches and the naming convention.
Create a Type Sandbox
To enable users to create sandbox Subsystems (branches), the administrator creates a
Type Sandbox
.
Follow these steps:
  1. Define a processor group that includes the following delivered generate and delete processors. The processors generate the branch and enable users to delete the branch when they are done with it. The processors can be used as is and do not require editing.
  • @GSANDBX
    The generate processor. When the user creates an Element of Type Sandbox in the trunk Subsystem in Stage 1 of the Development Environment and then saves the Element, the generate processor creates a sandbox Subsystem. The purpose of creating the new Element is to get the generate processor to run batch admin SCL that creates the Subsystem as follows:
    • Names the sandbox Subsystem with the name that the user specified when creating the Element of Type Sandbox.
    • Maps the sandbox Subsystem to the code trunk Subsystem that the user specified when creating the Element of Type Sandbox.
    • Creates the necessary data sets for this sandbox Subsystem.
  • @DSANDBX
    The delete processor enables the user to delete the branch after the changes have been moved to production, and there is no longer any need for this branch. When the user deletes an Element of Type Sandbox, the delete processor runs SCL that deletes the branch as follows:
    • Deletes the Element of Type Sandbox.
    • Deletes the sandbox Subsystem definition.
    • Deletes the data sets that were created for this Subsystem.
  1. Define a Type that executes these processors. To create the Type, specify these parameters only:
  • Name
    Specify a name that makes the purpose of the Type clear. You can specify any name you prefer. However we recommend naming it "SANDBOX" or "BRANCH."
  • Default Processor Group
    Specify the processor group that you defined in step 1.