Testing Workflow With Admin Migration Wizard
As part of the procedure for setting up workflows and documents, you can use the Integrity Lifecycle ManagerAdmin Migration Wizard (migration wizard) to test your workflows and documents configuration on a separate server before ultimately migrating a final configuration to your production Integrity Lifecycle Manager server.
For the purpose of migrating workflow and document admin provided objects, the separate server for testing your configuration is called the staging server and the Integrity Lifecycle Manager server that users connect to is known as the production server. By default the Integrity Lifecycle Manager server is always installed as a production server. The production server manages all aspects of Integrity Lifecycle Manager: workflows and documents, requirements, configuration management, and testing. The migration wizard allows you to test proposed changes thoroughly on the staging server before migrating those changes to the production server, avoiding the situation where live changes must be made in your production environment. The process helps you to work with the required admin provided objects to create a workflow that functions for your environment.
Admin Migration Server Configuration
| Production and staging servers must be installed on separate machines. Both machines must be running the most current server installations. |
To create a staging server, you must install a second Integrity Lifecycle Manager server on a separate machine and then configure specified properties on that server.
The staging server starts by using a copy of the Integrity Lifecycle Manager database from the production server. The two servers must have identical copies of the database or you cannot begin the initial migration configuration setup (later, changes to imported users and converted admin provided objects are automatically detected and can be imported from the production server). The database copy is created manually, based on the recommended procedures for the type of database you are using for your system. If assistance is required for managing the database, you should contact your database administrator.
In starting up, the staging server automatically obtains a binding administrative lock on the production server. The administrative lock means that no changes can be made to workflow and document admin provided objects on the production server. The binding establishes an association between the two servers: the staging server is the server you want to test your workflow changes on, and the production server is the server you want to ultimately migrate the changes to. At any time, you may also lock the staging server to prevent changes from being made in your test environment.
Once you make changes on the staging server, the migration wizard allows you to transfer those changes to the production server. After a successful migration, the production server then has the same administrative configuration in Integrity Lifecycle Manager that existed on the staging server. You can also elect to transfer only specific changes to the production server. States, fields, workflows, and other admin provided objects migrated from the staging server function in the same way on the production server. You can migrate admin provided objects repeatedly until all the desired changes are migrated.
| Releasing the lock on the production server means that the binding link between the staging server and production server is lost and the two servers are no longer synchronized. Further staging work therefore requires a new copy of the database from the production server, including items outside of the database such as trigger scripts and workflow and document report templates. |
Admin provided objects and components that are migrated include the following:
• administrative charts
• administrative dashboards
• administrative queries
• administrative report resources
• administrative reports
• change package attributes
• change package entry attributes
• change package types
• dynamic groups
• fields
• files under the data/public_html directory
• groups
• item presentation templates (including image files in the public_html directory)
• projects
• states
• document items
• time entries
• trigger scripts
• triggers
• types
• users
• ViewSets
• test verdicts
The basic steps for completing a workflow migration include:
1. Install and start the Integrity Lifecycle Manager server you intend to use for production purposes (the production server).
2. On a separate machine (the staging server), install the Integrity Lifecycle Manager server you intend to use for testing and migrating your workflow and document admin provided objects.
3. Place an administrative lock on the production server before copying the database.
4. Copy the database (and other necessary objects) from the production server to the staging server.
5. Perform a cold restart of the staging server in order to clear cache data.
6. Start the staging server, which automatically creates a lock binding between the staging server and the target production server.
7. Configure workflow and document admin provided objects on the staging server and test your configuration.
8. As required, manage administrative locks on the staging and production servers to keep the two databases synchronized.
9. Migrate your configuration from the staging server to the production server.
Related Links
