Configuration Post Go-Live using SDLC
Organizations using SDLC 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.
If your organization will not be moving from Test to Production, but using test for User Acceptance Testing (UAT) Only, please see:
If you are not sure your databases are in Sync, do not use Configuration Portability. If you have made changes in production regardless if you made them in test also, then your Test and Production Databases will not be in Sync (index and GUIDS). You must use the instructions found in Best Practice: Configuration Post Go-Live and you will need to manually move your configurations into Production. Going forward, you should not make changes to test.
Configuration Portability is the module that is used to move configurations between Test and Production. It is being replaced in an as yet to be determined (TBD) release with a new configuration migration assistant that will not rely solely on the 2 databases being in perfect Sync with one another.
To be added to the mailing list and be notified when the new Configuration Migration Assistant is available, please email Knowledge@alemba.
This page will advise how to effectively function in SDLC whilst minimizing the amount of effort that will be duplicated across the systems. The sections that follow will provide information on how to:
Develop and test screens in test and export to Production
Develop and test Workflows and export to Production
Export Workflows from Production to Test
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
Screen Changes
Workflow Changes
What you can do in Production
System Administration Settings
Data Import (People, CMDB items, etc)
IPK Workflow Rules
Call Templates
IPK and Workflow Scheduling
Skins
| Item in ASM | Item Type | Where Stored | Method of Moving | Who 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
Typical Mistakes that can cause data corruption
Source (TST) and other Targets are not synced with the Master Target (PROD) before development starts
Importing files from multiple environments into Master Target (PROD)
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.
See Also
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.
Last updated