Addressing a Production Application Defect

Critical defects which impact business operations must be addressed in a timely and judicious manner. This is opposed to non-critical production defects which can be addressed in a future release of an application.

The best strategy for preventing production defects is to have the proper functional and performance testing in place as part of a release management strategy to avoid deployment issues in the first place as a part of each sprint.

Testing should take into consideration the backward compatibility of the latest changes with the current inflight processes.

For example, if the latest production release contains a change to an existing process model, new instances of this process model must be started on the Test environment prior to the deployment of the changes in order to stage "production-like" data. These processes must be used for testing that the changes are backward compatible.

Consider the following options if a defect needs to be resolved immediately in Production in addition to the best practices for promoting and deploying applications. For all options, use a staging environment to help develop and test this hotfix. Also, determine the impact of all options on existing in flight processes as described above:

Option	Description
Application Hotfix	Apply an application hotfix to address the problem. It’s more desirable to address one isolated change than to roll back the whole application in addition to any database changes that are necessary. After applying a hotfix, there might be some lingering processes which will require intervention.
Rollback by Rolling Forward	Install a previous version of the entire application on the production instance.
Restore From Backup	This option will result in data loss of all applications back to the point of when the backup of both the application and database occurred. This should be considered as the last option if all of the previous options fail.

Warning: Restoring from backup should be your last resort as data loss will impact all applications.

Managing Existing Processes

Once the application defect is addressed, there may be remaining in-flight processes which also need to be addressed as part of your plan for this hotfix. The following options are available.

Option	Description
Process Upgrade	The Process Upgrade functionality is the recommended out of the box approach to upgrade existing inflight processes. Process Upgrade does not create a new version per updated instance as is the case with in flight process modification. Instead, process upgrade ports the instance to the target model version.
IFM Manager	The In-Flight Modification Manager (IFM) allows a designer to programatically update running process instances in bulk Consider the preparation time necessary to develop and test the automated model which performs the modifications The IFM manager will create a design object for each modified process instance both in memory and on disk. This means that the system will permanently and irreversibly consume more memory as a result of the inflight modification. Therefore, it’s advised to use IFM sparingly and on a limited set of models.
Manual Inflight Process Modification	Manual modification of each inflight process may be an option depending on the number of processes impacted, the complexity of the required changes and the number of resources available to make the changes. Similar to the IFM Manager, this will also create a new version of the process both in memory and on disk. This will have the same memory impact as the IFM Manager
Stop and Restart Processes	A purely data driven process model design provides the capability to stop and restart processes. There is also the option of stopping the process and having users start from the beginning of the process.

Topics

Addressing a Production Application Defect

Managing Existing Processes