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.