Application Deployment Guide

Skills Covered

Promoting a new application or changes to an existing application must always follow a predefined and controlled set of DevOps practices to ensure high quality and speed as well as to decrease risks.

The Appian Cloud standard offering includes 3 environments (Development, Test and Production), which many customers use as a starting point. Once the first application is in production, Appian recommends increasing this to a minimum of 4 environments, which allows more efficient maintenance and production deployment while maintaining development velocity in the Development and Test environments. A 4th environment as described below is also beneficial when managing concurrent development streams.

Deployment Pipeline

The advice in this guide applies to Appian version 20.1 and later

The available environments in a pipeline vary between organizations. Appian recommends to start with the standard 3 environments (Development, Test and Production) and to eventually increase the pipeline to a minimum of 4 environments as described below:

  • Development - all development activities are performed in this environment.
  • Test - changes are tested on one or more test environments to ensure that the changes are working properly and that they address the requirements. Typical tests for an Appian application include unit tests, functional tests, integration tests, user acceptance tests, and non functional tests such as performance tests. More than one test environment may be required to execute these tests. Please refer to the Recommended Environments play for further details.
  • Deployment Test - this environment is to be used to test the deployments to production and to perform the final round of functional and regression testing. Depending on your organization, this environment may have a different name and may serve multiple purposes. This environment must be a copy of the production environment. The packages deployed in this environment are identical to the packages deployed in production. A successful deployment in this environment guarantees a successful deployment in production.
    • If your organization does not use a Deployment Test environment, apply the deployment steps listed under “Test to Deployment Test” for your production environment instead.
  • Production - at the end of the pipeline, the changes are deployed to the production environment after tests are successful and changes are approved for deployment to end users.

The packages move through the pipeline from Development to Production:

Bulb“Compare And Deploy” With Appian

The recommended deployment approach to deploy Appian applications from Development to Production is using the Compare And Deploy feature of Appian.

To use this feature, you must adhere to the following best practices related to packaging and releasing applications on Appian:

  1. Do not design circular dependencies between different applications
  2. Build applications with independent life cycles

Additionally, you must have enabled the following:

  1. Configure the DevOps Infrastructure in Appian by connecting your different Appian environments.
  2. Enable the deployment of Appian applications across environments.

Deployment Process

After these configurations are in place, we recommend using the following process to package and deploy applications from Development to Production.

Step 1. Deployment from Development to Test

Deployments from Development to Test are frequent and are performed as patch deployments. We recommend deploying at the story level:

  1. Each story is developed within its own package
  2. Once the story is completed and tested by the development team, it is deployed individually to the Test environment for further testing and approval.

To deploy the changes related to a story using the Compare and Deploy feature, the developer follows the steps outlined below:

  1. If applicable, prepare the DDL database script containing the database changes related to the story and add it to the package.
    1. Please refer to the rerun-able DB SQL scripts play for more details
  2. If applicable, add necessary plug-ins to the package
  3. If applicable, configure the properties in the import customization file for the environment specific objects and add it to the package.
  4. Use the Compare and Deploy feature to deploy to the Test environment.
  5. After the deployment is successful
    1. Merge the import customization properties into a consolidated import customization file for this application. This file will be used for the deployment in Deployment Test and Production
    2. Merge the story’s DDL database script into a consolidated master DDL database script. This script will be used for the deployment in Deployment Test and Production. Please refer to the rerun-able DB SQL scripts play for more details.

If the implementation of the story resulted in changes in more than one application, for example changes in a shared objects application and changes in a business application, you must go over the deployment process twice: once for each application, starting with the application that contains the precedents.

Step 2. Deployment from Test to Deployment Test

Deploy to the Deployment Test environment when your application has been fully tested and approved and you are ready to move it to production. Deployments to the Deployment Test environment are performed at the release candidate level and can be considered practice runs for the deployments to production. These deployments are full application deployments.

To deploy an application to the Deployment Test environment the team responsible for production deployments follows the steps outlined below:

  1. Use the Compare and Deploy feature to initiate the deployment by comparing the corresponding application between the Test and Deployment Test environments.
  2. At the Prepare Package step of the wizard, select “Entire Application”
  3. If applicable, upload the consolidated DDL database script that has been previously created throughout the deployments to Test.
  4. If Applicable, select plug-ins to deploy to the Deployment Test environment.
  5. Update the name and description of the deployment to reference the identifier or name of the release candidate. Also add the reference to the deployment story if a story was created specifically to move the release candidate to production. This provides traceability between the stories and the changes in Appian.
  6. If applicable, upload the consolidated import customization file that has been previously created throughout the deployments to Test.
  7. Deploy to the Deployment Test environment.

Step 3. Deployment from Deployment Test to Production

Deployments to the production environment are identical to the deployments performed to the Deployment Test environment. As such, the recommended approach is to deploy the entire application with the same DDL scripts, plug-ins and import customization file as the ones used for the deployment to the Deployment Test environment. Appian provides the ability to easily deploy the same package to another environment as described in the Appian DevOps documentation.

Additional Considerations

Deployments can be executed remotely using the Appian Deployment REST API. Integrating this API with a CI/CD tool allows for setting up automated deployments pipelines.

If your organization wants to maintain version history of the Appian deployments outside of the Appian platform, we recommend performing the following:

  1. Export the deployment packages that are deployed from Deployment Test to Production
  2. Version these deployment packages in a Version Control System or in a shared repository alongside plugins, consolidated DDL database scripts and import customization files

Changes to the Appian Administration Console must be tracked as follow:

  • For changes that are exportable and importable, we recommend to version control these configuration settings like the application artifacts.
  • For changes that do not follow this pattern, we recommend maintaining a deployment plan document listing the steps and settings that must be configured.