Deploying an Application Hotfix

The information provided in this guide is provided within the scope of the application hotfix development and deployment to a production environment. The guidelines and practices outlined here are not meant to be used for supporting concurrent feature development.

IMPORTANT: It is recommended to only create hotfixes for critical changes that cannot wait until the next version of the application is released. This is to keep disruptions to the development team to a minimum and to avoid incurring the cost of applying the change twice (once for the production version and again for the latest version in development).

Key Concepts

1. Production-Like Environment
   • Development of the hotfix must occur in a production-like environment.
   • Whatever application packages, plugins, database structures, and other artifacts that exist in production must exist in the environment to be used for hotfix development.
2. Collision Detection
   • A collision occurs when a hotfix requires making a change to an artifact that has changed in the development environment since the application was last released to production.
3. Merging Objects
   • Manually applying the changes implemented in a hotfix to the latest version of the application in the development environment.
   • This should take into account how the hotfix relates to changes that have been introduced since the application was last released to production.
4. Active Workstream
   • Any development stream that is part of standard development processes.
   • For example, if Release 1.0 is in Production, a team may be working on an active workstream of 1.1.

CORE PRINCIPLE: Work on a version of the artifacts that matches the one in production.

Collision Detection

No Collision

1. Confirm that the artifacts that need to be modified for the hotfix are the same in production and in the development environment.
2. Hold off on any new feature development that would require modifying the artifacts that will be involved in the hotfix.
3. Develop hotfix changes directly on the latest version of the application in the main development environment.
4. Create a patch containing only the artifacts involved in the hotfix.
5. Test the hotfix in a test environment.
6. Release to production.
7. Resume feature development on the artifacts involved in the hotfix.

Collision

1. Confirm that the artifacts that need to be modified for the hotfix are not the same in production and in the development environment.
2. Confirm the hotfix development environment has the exact same version of the application that is in production.
3. Develop hotfix changes on the hotfix development environment.
4. Create a patch containing only the artifacts involved in the hotfix.
5. Test the hotfix in a test environment.
6. Release to production.
7. Manually merge the hotfix changes to the latest version of the artifacts in the main development environment.

Impact Analysis

1. During the next development, impact analysis of the changes required by the hotfix must be completed.
2. All artifacts to be changes should be tracked in documents, spreadsheets or other tools to facilitate completion of development and merging. For example, the Application Hotfix Change Log.
3. If there is an existing development stream, all hotfix changes must be evaluated against that set of artifacts. Artifacts may have changed in the active workstream following their initial release into production.
4. Leverage the change log to review proposed changes against the active workstream artifacts.
5. Complete a collision detection exercise to determine the impact of the hotfix changes on the active workstream.

6. If a collision is detected, a merge strategy should be outlined between the hotfix developer and the active workstream development team.

   1. Database and CDT Changes - the table and CDT should be updated in the development environment, and impact analysis run to push the changes across the environment.
   2. Process Model Changes - the model in Development should be manually updated with the changes made in Production Hotfix, and tested thoroughly before the next release.
   3. External System Changes - the external systems should be updated in all environments to reflect necessary changes.

7. This strategy should be documented in the change log.

Hotfix Procedure

1. Environment Set-up

   1. Confirm the hotfix development environment contains the application packages, plugins, database structures, and other artifacts that exist in production.
   2. Data can be staged as needed.

2. Development

   1. All development will be completed by following Appian Best Practices
   2. Throughout the hotfix development cycle, the hotfix owner must complete impact analysis
   3. Upon development completion, create a patch containing only the artifacts involved in the hotfix.
   4. Test the hotfix in a Production-like test environment.
   5. Release to Production.
   6. Ensure hotfix application is in version control or other change management solution.

3. Merging

   1. Using the collision notes captured previously, merge the hotfix into the active workstream If no collision is present, the hotfix may be merged in directly If a collision is present, follow the strategy outlined to manually update the active workstream artifacts
   2. All merges should be regression tested to ensure the application functions as expected.