Deployments in Appian

Overview

This page is about the deployment process in Appian and the different ways you can deploy updates to your applications. To learn how to deploy your applications and packages, see deployment types.

The deployment process

Deploying is moving a set of objects from the source environment to the target environment in order to release updates to your end users.

A package is a collection of Appian application changes that you can deploy to another environment. Preparing a package is an important step in the deployment process and involves understanding what changes you need to deploy and how these changes will affect your target environment.

You can deploy multiple packages from multiple applications simultaneously. To help you group packages that need to be deployed together, you can organize related packages using releases. Releases provide better traceability and make it easier to coordinate deployments across multiple packages, applications, and teams.

Make sure you understand object-specific behavior while preparing a package for deployment. In your application, you check your application for missing precedents and add the precedents to the application. In the package view, you can perform the same analysis for an individual package.

Once you've prepared a package, you can then deploy it from a source environment to a target environment.

During deployment, the definition of each object in your package is exported from the source environment into an XML file. Appian bundles these XML files into a ZIP file, which is used to move the objects to the target environment.

Information about related objects is preserved across the deployments. In most cases, the related objects themselves are not automatically exported. They must be explicitly added as objects within the package, or already present in the target environment.

Deployment contents

In addition to deploying enhancements, you can also use the following types of packages to deploy new applications and change administration settings in the target environment:

• Applications: Deploy an entire application when you are introducing a completely new business solution into the target environment.
• Database scripts and plug-ins: Deploy only database scripts and plug-ins to make changes in the target environment that support a later deployment of changed design objects.
• Admin Console settings: Deploy only Admin Console settings when you want to make changes to the Administration settings in the target environment.

For auditing purposes, you can always find all changes introduced to an application in the Deploy view.

Common deployment paths

Some common deployment paths include:

Source Environment	Target Environment
Development	Test
Development 1	Development 2
Break Fix / Hotfix	Development
Test	Production

The optimal approach depends on the security considerations of your source and target environments, as well as the deployment contents you have. Whether you are deploying one or more applications, packages, database scripts, plug-ins, Admin Console settings, or a mix of these can impact how you decide to deploy.

Deployment types

There are three types of Appian deployments:

• Direct deployment: Deploy applications, packages, plug-ins, and database scripts to connected environments using Compare and Deploy, a set of guided steps within the platform.
• External deployment: Customize your own deployment process with the native deployment APIs to integrate with your external deployment pipeline.
• Manual deployment: Manually export and import applications and packages between environments using ZIP files.

Additional logic can be run after direct or external deployments by configuring a post-deployment process.

Direct deployment

Direct deployment provides a guided push-button deployment of applications, packages, plug-ins, and database scripts across connected environments.

This out-of-the-box approach requires minimal setup and supports continuous delivery. For most teams, Appian recommends using direct deployment.

Learn more about compare and deploy.

Manual export and import

You may have constraints on specific environments or packages that prevent you from taking advantage of direct deployments. If that's the case, you can also manually export an application or packages from a source environment and import it into the target environment.

When you export and import packages, rather than directly deploy them, you must manage certain dependencies manually. For example, exported packages do not contain database scripts or plug-ins.

Learn more about manual export and import.

You can also programmatically export applications and packages using export APIs. To learn more, see the external deployment section below.

External deployment

Our native deployment APIs enable you to not only export, inspect, and import programmatically, but also customize your own deployment process.

The deployment APIs offer five endpoints that allow you to deploy combinations of Admin Console settings, applications, packages, import customization files, plug-ins, and database scripts. You can call all of these APIs from external tools, such as Jenkins.

Use these APIs to trigger deployments and integrate your Appian release into an automated pipeline. Configure your pipeline once and run it the exact same way for all future deployments, saving time and avoiding manual errors.

Learn more about native deployment APIs.

Package dependencies

Beyond the objects in your package, a successful deployment may also depend on the following supporting files and settings.

Application configurations

These application-level settings are used to construct the application in the target environment. The configurations can also add functionality like centralized application documentation and default security groups. Application configurations are always deployed when an application is new in the target environment. A package can contain just your application configurations or include application configurations alongside additional objects and enhancements.

You can manage this dependency by adding application configurations to a package during development or deployment. Alternatively, you can manually update the settings in the target environment.

Import customization file

You may have to include an import customization file in your deployment if certain objects and configurations require environment-specific values, such as usernames and passwords. This file also enables you to deploy unchanged objects and trigger a sync for record types. Appian generates a template import customization file for you, which you must modify as appropriate to the target environment.

You can manage this dependency by adding an import customization file to a prepared package, during compare and deploy, or during a manual import.

Database scripts

You can directly deploy database scripts alongside your application changes or allow Appian to manage your database structure. To learn more about managing data through deployments, see Managing Database Scripts for Deployment.

Plug-ins

Plug-ins allow developers to extend Appian functionality. On Cloud sites, system administrators can deploy Cloud-approved plug-ins to an environment through the Admin Console. On self-managed sites, plug-ins can be hot deployed by placing the JAR file in the specified directory. In addition, you can deploy plug-ins that exist in one environment to another using compare and deploy and deployment APIs.

Admin Console settings

Certain objects may rely on specific Admin Console settings for successful deployment. For direct and manual deployments, you must import these settings prior to deploying the package of dependent objects.

Post-deployment processes

A post-deployment process is a process that automatically runs after a direct or external deployment has finished on an environment. From this process, you'll be able to access key information about the relevant deployment.

Post-deployment processes provide flexibility, which allows you to automate tasks, leverage third-party tools, and customize your workflow. Automating your post-deployment steps reduces manual tasks and the potential for human error.

Object behavior in target environments

The system identifies whether an object already exists in a target environment based on the presence of an object with the same UUID.

If an object already exists in the target environment, the system determines whether to overwrite the existing object based on the object's comparison status during inspection and any related settings in the import customization file.

If the system determines that the existing object should be overwritten, the system does one of the following:

• If the object type supports versioning, the system creates a new version of the object. This new version is created even if the only modification was to its security role map.
• If the object type does not support versioning, the object in the package overwrites the existing object.

Because objects in a deployment aren't updated simultaneously, users may see some inconsistencies in their application behavior as objects are updated. For example, during a lengthy deployment, a constant may be updated but the process model that references the constant may not have been updated yet. To avoid these inconsistencies, schedule your deployment outside of your organization's working hours.

During deployments that include a synced record type, the record type must successfully sync in the target environment before it will be available. This may mean that your record type will be unavailable to users, processes, or APIs until the import is complete.

Feedback