Topics

    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.

    © 2024 Appian. All rights reserved.