Guestpost: Freeze! You’re under Upgrade

I am happy to announce that today’s article is a guest post by Roney Uba. He’s a friend and Automic Expert from Brasil. Enjoy!

Depending on the size of your Automation Engine environment, you may face challenges when doing version upgrades. This may be the time span, tests or concurrent changes. Because of this, I would like to show you some ideas on how to handle it using principles discussed by Philipp. 

But before we get into it, let me tell you a small story.

I’m writing this while I start my journey towards new accomplishments, and I cannot find a better time to type than during a 10 hour flight across the Atlantic.

No sarcasm! I’m serious! I’ve even used a seat assignment strategy in which I booked the aisle seat with the seat next to me being empty and the following already reserved. This way, other passengers avoid reserving that middle seat and I have a few centimeters more.

On this journey, I said goodbye to my old me, left my home, my country, and focused on the one thing that will change the world – Automation!

But now, let’s get back to topic. When you are doing an upgrade, you start with the Development environment, then Acceptance and finally Production, for a typical 3 tier environment.

But, when you have your Development running on the new version, the objects cannot be transported anymore with DB unload/DB load, because this is only possible when going from an older version to a newer version. Thus, your system is frozen for changes until you update the other environments, test what is needed and finish the Production setup.

To overcome this, let’s apply Philipp’s guidelines and see the solution.

WHAT
Better coordinate the upgrade project activities with the concurrent object changes that are needed for process improvement or business requirements, avoiding long freeze periods and avoiding direct manual changes to the Acceptance and Production environments.

HOW
Expand the 3 tier environment to a 5 tier environment, meaning that all non-Production environments will have a pair of old and new system version.
In order to avoid synchronization problems and manual direct changes, the single point of entry for all changes to the environment is the old Development system/client.

DESIGN
Having the single point of changes being the old Development environment will make sure the transported objects can be unloaded and then loaded to both the old and new versions.
In order to make all environments synchronized, the transport routes will happen in parallel, like the image below.
Also, depending on how you translate Development parameters/values to other environments, you need to work on setting up these new rules. For example, using DB change utility to translate a server name from Dev to Acc will need to be duplicated and adapted taking into account the new destination of the transport.

In addition, you may need to correct some problems with your job configuration, because of incompatibility between versions, like a different number of values passed to a script function. This can also be converted during the transport cycle to the environments on the new version.

Other than this, you may already plan changes to your job configuration, to take advantage of the upgrade process. For example, include the use of queues that were not explored on the old system. If this is the case, include the requirements on the WHAT part and design how this will be done while fulfilling the previous requirements.

And a last reminder: changes going to Production on the old system (before the upgrade ends) need to be tested on the old Acceptance system.