For enterprise customers for whom Remedy is a mission critical application, taking any downtime for upgrades is not acceptable. This is the reason that customers build staging environments to manage the upgrade process and cut over to this environment after the validation is complete.
This whole process leads to significant investment in time, resources and cost making upgrades a painful experience for the customers.
In Remedy, we have been evolving how upgrades are done over the years, below are some of the key improvements
Platform Zero Down Time Upgrade
We introduced platform zero down time upgrade with our 9.1.04 release. The key concepts are as follows
1- We ensured that the database schema is backward compatible, enabling both our old and new versions to work against the same schema.
2- The process we recommend is a rolling upgrade by taking individual servers out the servergroup and then upgrading them and adding them back to the servergroup
3- During this process, we put the system in an upgrade mode, meaning none of the new features are activated yet
4- Once the last server in the servergroup is upgraded, we then take the system out of the upgrade mode and the new features are now activated.
5- In the event of any failure, we seamlessly rollback the system to the previous good state preventing any system availability issues
Deployment Manager (D2P)
Another key innovation we introduced is deployment manager ( D2P ). D2P helps bundle all content i.e fremedy application objects , data , binaries into a deployable package. We then allow the package to be deployed on the system. This package can be entirely rolled back in case of any issues after the package application
This process allows for all changes to be made on the Dev systems, packaged and seamlessly apply the package on QA or prod systems without incurring any manual steps in these environments
Starting with our 1808 release, we moved away from providing an installer for ITSM applications and instead started delivering all the release content as D2Ppackages.
The key advantages of this method are
1- Allows for deployment from a single server , the system will automatically distribute content to other servers in the servergroup
2- Provides ability to rollback the entire package in case of any issues.
3- Provides the ability to upgrade ITSM application without any downtime
We recommend upgrading in-place to take advantage of the above capabilities , the high level process we recommend
1- Upgrade Dev environment, reconcile customizations and create a D2P package with the modified content.
2- Upgrade QA environment, apply the D2P package and perform validation. Make any needed adjustments to the D2P package based on the testing and prepare a final D2P package
3- Upgrade Production environment and apply the final D2P package, perform smoke tests and then go-live
Please share any comments or feedback on the proposed upgrade process