Table of Contents | Next | Previous

Topic 6. Maintenance and quickfixes

6.6 Emergency fix “fastpath” Situations

One of the main goals of this book is to describe how to move changes through a Portal environment that is made up of several different stages along the way from development and test, through staging to production.

There are various reasons changes need to be made to a working portal system.   Creating an entirely new portal solution release that includes new functionality and may also require some new complementary product software be installed, can be a very large undertaking.   As described in section 3.1 Portal Environment configurations, after the components are created in the development environment, they are moved over to QA where they are integrated and tested initially.   The release moves from QA on to the user acceptance testing (UAT) environment and then over to staging for extensive performance testing, before finally being moved over to the production servers.    It is important to carefully tag and version every component along the way as well as document the results and effects of any changes made to the portal release or the portal environment it is running in.   In most organizations, this is an ongoing process that takes time for a release to move from one end of the chain to the other.

There may be cases where a critical update, either to the Portal product itself via one of the above mentioned maintenance delivery vehicles, or an urgent fix to part of the release that was developed by you, needs to be fast-tracked through the pipeline of environments to the production server.  

The figure below illustrates this concept of how an emergency fast-path fix to production would by-pass the traditional staged approach of applying updates through the environment.

In an optimal world, these changes would never need to be made.   However, to mitigate the impact that an event of this type will have in your organization, it's best to have a plan in place to deal with application of fixes that are urgently needed in production.

Unless you maintain a duplicate pipeline of servers available for this purpose, then the normal flow of a release deployment will need to be interrupted for the processing of the higher priority emergency fix.

The actual steps that need to be taken to deploy the emergency fix will vary depending on the number of components affected by the emergency fix that needs to be made and the resources available to test the emergency fix as well as the state of the staging server where the changes need to be tested.   At a minimum, you may need to make the emergency fix testing take priority over the test of the next release already in progress.   At a maximum, you may need to consider rolling-back changes made to a staging server if a differential release is deployed on it for testing that has not yet reached the production server environment.    Whatever situation you are in, the site's downtime can be positively impacted if this situation is anticipated and planned for.

Abstract - This article describes how to deal with Emergency fix “fastpath” Situations