When deploying process model changes to a higher environment, in-flight (active) process instances continue to use the pre-deployment process model version. Additionally, the pre-deployment CDT version is used within these in-flight process instances. However, any objects referenced by that process model, including constants, expression rules, interfaces, other processes, etc., will always run the latest version. Developers must take precautions to ensure that both existing and new processes will work after the deployment. In-flight testing is used to ensure all modified objects are compatible with legacy processes and have expected behavior for both active and new processes. In-flight testing is not needed for first-time releases of an application because no process instances exist in the production environment prior to deployment. However, in-flight testing should always be conducted in preparation for subsequent production releases.
A Pre Production environment is best suited for in-flight testing. The Appian version and application version should mimic the current Production versions in order to maximize testing validity. In a three environment ecosystem, the Test environment is typically used to push code each sprint from the Development environment. Thus, the Test environment application version will most likely not match the Production environment application version after a given development sprint. While technically possible to conduct in-flight testing using a 3 environment ecosystem, it requires additional management and testing each sprint. With a stable Pre Production environment that continually matches Production regardless of sprint development, in-flight testing becomes truly valid and simpler to conduct.
In-flight testing begins prior to deployment to a Pre Production environment. Kick off every process model in the Pre Production environment which is expected to have active instances during the actual Production deployment. This can be done manually or via automated testing tools like FitNesse for Appian. Ensure that each path within a process model is accounted for when staging active instances so that each part of a process model that changed since the last version may be tested. After the deployment is finished, complete the staged in-flight instances. Validate the results by comparing the intended process behavior to the actual behavior.
If all pathways within each process instance cannot realistically be accounted for in testing, weigh the pros and cons of prioritizing a fixed set of in-flight instances to stage. Value may be based on the following characteristics: