Have you ever struggled migrating configurations from Development to Test environment and then to Production?
If the answer is yes, you are not alone. I think this is the one of the most common issues when managing multiple environments in medium-large Maximo projects.
Keeping several Maximo environments in synch while ensuring a fast release cycle required in today's projects is challenging and typically involves two flows.
- The first flow of configuration changes is the classical release flow. You have to release configurations from Development to Production through all the intermediate environments and entails the build of some sort of 'configuration package' that is deployed on each environment.
- However, in the real world, all those environment will loose sync after some time so we need to realign back through the chain using a database cloning procedure (backup and restore). This is a well known practice to rebuild a development environment ensuring all
In my experience I have seen a lot of different approaches to build 'configuration packages'.
- The simplest form of package is brain memory. This is the simplest form of package. It is applicable only when there is only one Maximo administrator/developer but is very unreliable and there is no change log of what has been released.
- The second type of package is a text file with precise instructions of what configuration must be applied. This is the minimum level that I personally adopt on small projects involving up to 2-3 environments and 1-3 administrators/developers. The file can be prepared by the developer and passed to the system administrator (together with automation scripts, application XMLs and other configuration files) to be deployed. Such packages can be stored on a shared folder for tracking purposes or versioned on a CVS/SVN repo.
- Instead of having unstructured text files, some teams tries to define a standard template for documenting configurations. These are typically Excel spreadsheets. I do not personally use this approach because it is quite compelling to find a set of templates to cover all possible kind of configurations and there is no great advantage over the text-file approach.
- The official approach is to use the IBM Migration Manager. I have seldom used this approach and is perfect for large environments and big teams. The biggest problem of this tool is that it is not really easy to understand what configurations are stored in the package since it actually is a zip file containing large XML files.
I have recently developed my own approach based on MxLoader to overcome limitations of the approach 4 thus providing a more reliable process than approach 2.
In MxLoader 6.1 I have released a set of Object Structures and templates specifically developed for migrating configurations: Conditional Expressions, Reports, Object Data Restriction, Attribute Data Restriction, Domains, Database Objects/Attributes/Relationships/Indexes, Automation Scripts, Application Signature Options, Security Group Authorizations, Actions, Roles, Escalations, Workflows, Communication Templates,etc.
I typically use the templates with the 'Query' action to extract the configuration from the development environment. I incrementally build the appropriate where clause in cell D1 to extract the minimum set of records. When I have finished building the package, I switch to the integration environment in the Config sheet and use the 'Sync-AddChange' action to apply the configurations.
The main advantage of this approach is that it is really easy to see what configurations are in the package and what changes are actually applied to the production environment.
I encourage you to
download MxLoader and give it a try. I will do my best to publish some tutorials in the next future about migrating configurations using such great tool.
Labels: advanced, configuration, mxloader
