Recommended Release Management Process

The Release Management process must be carefully planned and managed. This section contains important considerations that must be addressed when setting up Release Management. A sample Release Management workflow is also included here to provide a tangible example of a working scenario.

Important Considerations

  1. All environments must share the same IVS Database. If the same IVS is not shared, then a detached migration must be performed. Make sure the two environments have the same OIPA baseline before performing the detached migration.
  2. The initial setup of a development track(s) should include setting the environment to the current view of production.
  3. Configuration for a given project, which is slated to move to production, will first perform all of its testing between the development environment and its Development QA environment.
    1. Configuration Packages within a Development Track should be named using a consistent naming convention that identifies the purpose of the configuration. A recommendation is that the Configuration Package name include: Project Name, Configuration Release, Name of the Feature/Function, and the Fix # (if applicable: the first release to QA will not have a Fix #). An example of a configuration name might be Term2: Build3: PremiumPayment for the first time it is released to QA. Names cannot be reused; they must be unique. If a similar name is needed append a date to the name to make it unique.
    2. For each build or drop to QA within that environment, there will be correlating Release Packages assigned.
    3. At the end of final sign-off by QA for a given build or drop that is set to go to production, there will be multiple Release Packages.
  4. When configuration is ready to move from a Development Track to production, a production pipeline Release Package should be created. This will include all of the configuration changes that are to move to production.
    1. The Production Pipeline Release Package will be made up of the rules within the Configuration Packages of the Release Packages to the QA environment within the Development Track.
    2. The Release Packages to the QA environment within the Development Track should be examined in reverse order from which they were migrated to QA.
    3. For each Release Package, the rules within each of the Configuration Packages should be added to a new, single Configuration Package for the Production Pipeline. In this way, it will be clear when a rule has been migrated multiple times, and only the current version of the rule will be included.
    4. Once all of the QA Release Packages have been examined, and all of the rules within the Configuration Packages have been added to the new Production Pipeline Configuration Package, the Production Pipeline Release Package may be created.
    5. All Plan and Company data being added or updated will require scripts, and should be added as "Non-Palette" release management items.
    6. All updates to Chart of Accounts, Requirements, Data Dictionary and Translation Editor require table moves and should be added as "Non-Palette" Release Management items.
  5. When migrating to the Production Pipeline Development environment, it will be necessary to merge all of the rules and check for conflicts. This is not a systematic process – the reason being the Production Pipeline represents the current version of production. Changes to the actual production environment may have occurred since the start of the Development project that is now ready to be migrated to production. Diff Report functionality provided in the Rules Palette can be used to compare the development track with the production track. Use the summary diff report option to view all differences. The Rules Palette help has comprehensive instructions for using this feature. Configurors must review to determine if the rules being migrated are to be:
    1. Added: New rule that is simply added to production.
    2. Deleted: Rule that did exist that is to be removed from use.
    3. Edited: Changes made to an existing rule.

    When the merge of Development rules into the Production Pipeline occurs, a new single Configuration Package should be created within the Production Pipeline environment. As the rules are being analyzed and merged into this environment:

    • An Add of a rule will require the creation of an INSERT script that will then be used to insert the rule into the Production Pipeline Development environment. Once the rule has been inserted, the configuror can then go to the rule and check it out within the Production Pipeline Development environment. At check-out, the configuror will add the rule to the Production Pipeline Configuration Package (This will now be noted as an UPDATE within the Configuration Package.) An additional step is required to then modify the contents of the Configuration Package for that rule to change the "UPDATE" to an "INSERT." This requires a script to be run in the database.

    Script Instructions:

    1. First, find the ConfigPackageContentsGUID by picking it from the list of contents: SELECT * FROM IvsConfigPackageContents WHERE ConfigPackageGUID IN ( SELECT ConfigPackageGUID FROM IvsConfigPackage WHERE ConfigPackageName = '{Insert Config Package Name Here}' )
    2. Then insert it into this query (be careful to use the ConfigPackageContentsGUID, NOT the ConfigPackageGUID):

      UPDATE IvsConfigPackageContents SET ActionCode = '02' WHERE ConfigPackageContentsGUID = '{Insert ConfigPackageContentsGUID Here}'

    3. To see the different actions available for a Configuration Package Contents record, you may run the following query:

      SELECT * FROM IvsCode WHERE CodeName ='IvsCodeDBTransactionType'

  6. A delete of a rule requires some research. Analysis will determine if the rule ever existed in Production. If it did not, then there is no additional work to be done, and the rule is NOT added to the Production Pipeline Configuration Package. If the rule DID exist in production and it is determined that it should be deleted in the Production Pipeline, then the rule will need to be deleted within the Production Pipeline Development track and added to the Configuration Package.

    Analysis Instructions: Determining if a rule exists in the Production Pipeline requires a Find Best Match query. You cannot query by GUID because if a rule was created in the Production Pipeline AND the Development Track while both were in separate development cycles, the same rule will have different GUIDs. To perform the Find Best Match query, you'll need to identify the unique index of the table. For example, the AsTransaction table's unique index consists of PlanGUID and TransactionName, so the find best match query would be:

    SELECT * FROM AsTransaction WHERE PlanGUID = '{Insert PlanGUID Here}' AND TransactionName = '{Insert TransactionName Here}'

    If this returns a record, you must delete that record and all of its references (e.g. if you're deleting a transaction, make sure to delete any Business Rules with that TransactionGUID attached to them, along with all other related records).

    1. An edit, or merge, of the Production Pipeline and the QA rule will require the rule to be checked out in the Production Pipeline, added to the new Production Pipeline Configuration Package, merged with work completed, and checked back in within the Production Pipeline environment. This does not require any extra analysis, but be careful not to overwrite any existing functionality while adding your new functionality.
    2. All Plan and Company data being added or updated will require scripts, and should be added as "Non-Palette" Release Management items.
    3. All updates to Chart of Accounts, Requirements, Data Dictionary and Translation Editor require table moves and should be added as "Non-Palette" Release Management items.
  7. Because of the potential, inherent volatility associated with a merge, full regression testing of your Production Pipeline is recommended before the final deployment to the Production environment.
  8. When all of the rules have been merged into the Production Pipeline development environment, and there is a single Configuration Package containing all rules that are to be migrated through the Production Pipeline, follow normal Release Management deployment procedures, and there will be no more merge work required.
  9. After the final release to the Production environment, the Development track used for the Production environment should be reset to match Production, setting it up for further project work.