Moving Configurations, Workflows and Screens From Test to Production

Most organizations will have a Test and Production System. It is vital for SDLC that development not be done in Production but rather, in Test and then Promoted.

This page will advise how to effectively do this whilst minimizing the amount of effort that will be duplicated across the systems. The sections that follow will provide information on how to:

  1. Develop and test screens in test and export to Production

  2. Develop and test Workflows and export to Production

  3. Export Workflows from Production to Test

  4. Implement System Settings/System Administration Change Control for your Production system

Summary of the Process for Moving Work Packages from Test to Production

Before you begin a new body of work - Back Fresh to Test

At this restore Point - No changes should be made in Production and concurrent projects developing in the newly refreshed Test system will need to Sync their timelines to allow for the Test Database to be refreshed without impact to one another.

What should not be done in Production

  1. Screen Changes

  2. Workflow Changes

What you can do in Production

  1. System Administration Settings

  2. Data Import (People, CMDB items, etc)

  3. IPK Workflow Rules

  4. Call Templates

  5. IPK and Workflow Scheduling

  6. Skins

Item in ASMItem TypeWhere StoredMethod of MovingWho Can Execute

People Records

Data

Database

Manual/Import

Customer

Portal System

Data + Configuration

Database

Config Port/Import Screens/Manual (System Admin Settings)

Customer

Portal Skins

Screen Design

Database

Manual

Customer

Portal Menus (My Options)

Data

Database

Manual

Customer

Service Actions

Data

Database

Manual/CSV export/import

Customer

Services

Data

Database

Manual/CSV export/import

Customer

Stakeholder linkages

Data

Database

Manual

Alemba

Service Level Agreements

Data

Database

Manual

Customer

Email Templates

Screen Design

Database

Config Port/Import

Customer

Email Subject Headers (Email Subjects on Message Types)

Data

Database + Local XML Files

Config Port + Manual copy of XML FILes

Alemba

Email Processing Rules (IPK Workflow Rules)

Configuration

Database

Manual

Customer

Language Labels

Data

Database

CSV Export/Import

Customer

Workflows

Data

Database

Workflow Import

Customer

Screens

Screen Designs

Database

Config Port/Import Screens

Customer

Terms Used

  • The Production (PROD) system is the master target system - the final destination for all the changes being developed

  • The Test (TST) system is the source system - where all the changes are developed

Best Practice

Required Export / Import Sequence

The import and export sequence is critically important to a successful outcome. Follow these steps to ensure all changes are developed on the correct database and imported successfully to the master target system.

For Cloud Clients: You will need to coordinate and Schedule this change work with Alemba so that the requisite backup and restore actions can be carried out as and when required.

Summary of Steps

  1. The first order of business is to Sync your Production and Test Databases. This is done by taking a copy of Production and restoring it to Test. Copy the Production database to your Test environment before you begin any development.

  2. Develop the required screens, emails, and system setting changes on the TST system. When complete:

  3. Perform User Acceptance Testing and Regression Test any existing configurations you have changed

  4. Move your Changes to Production

  5. Regression test to ensure the import was successful

    • If testing reveals there were problems with the changes or the import, go back to Step 2 and try to assess where the disconnect happened and correct it.

  6. Once the import is done and you have verified that everything is working, re-enable logins and the service action(s).

Best Practice

Back up the Target environment(s)

  • Backup routine should always occur to facilitate rollback if needed

  • If using a VM, you can snapshot the VM

  • Cloud Customers should log a ticket with Alemba Cloud Services at least 5 days prior.

Best Practice

Code and configuration freeze on Target environment(s)

  • Configuration changes should only be made on the Source system (TST)

  • Manual changes should not be performed on Master Target (PROD)

    • Manual changes risk being overwritten by the process

Best Practice

Be specific

  • Only export and import the specific elements you need

Typical Mistakes that can cause data corruption

  1. Source (TST) and other Targets are not synced with the Master Target (PROD) before development starts

  2. Importing files from multiple environments into Master Target (PROD)

  3. Importing in the wrong sequence

    • For example, if you import a workflow that needs custom screen sets that have not yet been created in the System Administration settings or imported into designer, then the workflow will come in "fractured" because the screens it needs are not present.

    • You cannot import screens until the screen set has been created in System Administration because there is nothing to link them to yet.

    • Similarly, if that workflow has rules written that depend on values in a DropDown configured on either the screens or the System Administration settings, such as Request Phase, etc and they do not exist, this will also create a situation where your imported workflow will not work.

    • Always import/reconfigure in this order: System Admin Settings -> Screens -> Workflows.

Spreadsheet Template for Tracking System Administration Changes

Alemba can provide a template for you to use that will include the options for documenting your system.

**Alemba Cloud Customers

Alemba Cloud Customers will need to contact Alemba through the Self-Service Portal and coordinate the back-fresh from Production to Test as and when needed. Please try to give a 5-day advance notice so that it can be scheduled.