This page outlines the various methods to deploy a package from one environment to another, and which method is best for each type of environment.
When you deploy a package, changes are taken from the source environment and moved to the target environment. Some common deployment paths include:
|Source Environment||Target Environment|
|Development 1||Development 2|
|Break Fix / Hotfix||Development|
The optimal approach depends on the security considerations of your source and target environments, as well as the type of changes you have. Whether you are deploying one or more applications, packages, environment specific data, Admin Console settings, or a mix of these can impact how you decide to deploy.
There are three methods for deploying a package in Appian:
Additional logic can be run after direct or external deployments by configuring a post-deployment process.
For auditing purposes, you can always find all changes introduced to an application in the deployments view.
If you're an Appian RPA customer, remember you'll need to package and deploy robotic processes separately from applications. Learn how to deploy robotic processes and apps.
For production environments, we recommend performing any deployment activities, including inspections, during off-peak hours. If necessary, a maintenance window can be scheduled in the Administration Console. Also, consider adding a post-deployment process to your application to automate tasks and make your development lifecycle more efficient.
If you are moving complete applications from a staging environment to a production environment, take standard precautions to ensure continuity by creating a backup of your production objects. If the import should fail for any reason, this allows you to restore the previous state of the application.
To create a backup of your production objects, export all of the existing objects associated with your application.
Compare and deploy is the easiest and recommended method of deployment. If your DevOps infrastructure is set up, you can enable these connected environments to interact and directly deploy changes from one to another without manually downloading and uploading ZIP files. For deployments to higher environments such as Production, you can require a review process by enabling it in the Administration Console
The compare and deploy feature guides you through a few straightforward steps:
Within compare and deploy, you can deploy:
If you're unsure about what you should deploy, check the table below to see which best matches your use case. You'll be prompted to choose one of the first three options when you reach the Prepare deployment step.
|Deployment Contents||When to Use||More Information|
|Entire application||Deploy your application configurations and all related design objects. Use if the application does not exist in your target environment.||You can include database scripts and plug-ins with your application deployment.|
|Package||Create a package or select an existing package to deploy a set of changes to your target environment. Learn how to create a package.||You can add application configurations, database scripts, and plug-ins to a package during development and when you deploy your package.|
|ONLY database scripts or plug-ins||If your application already exists in your target environment and you only need to deploy plug-ins or make changes to the environment's database via scripts, you can deploy these changes without objects. Database scripts and plug-ins can only be deployed to a target environment using compare and deploy if you are an application administrator.||To deploy database scripts and plug-ins without other objects, the application must already exist in your target environment.|
|Administration Console Settings||If you need to change Administration Console settings, you can export specific settings from your source environment and import them into the target environment. You can import an application or package along with Administration Console settings via the Administration Console.||Certain settings that are specific to a given environment cannot be deployed, such as API keys or certificates.|
|Import customization files (ICF)||Use to change or configure the values of certain objects or settings during deployment. Use ICFs for values that vary between environments or that are not exported for security reasons, such as passwords.||When exporting or deploying objects or settings that can be customized, an import customization
To deploy database scripts and plug-ins directly to a target environment, the Allow deployments with plug-ins and Allow deployments with database scripts settings must be enabled for the target environment. Learn more about deployment settings in the Admin Console.
Once you've determined what needs to be deployed, check that your deployment contents are prepared and ready to be sent to your target environment. If you're deploying a package, make sure that you've properly prepared it for deployment.
After everything has been prepared, it's time to start the compare and deploy process.
To start compare and deploy:
If you don't see any connected environments available, see DevOps infrastructure to learn more about setting up connected environments for deployments.
The Prepare Deployment step helps you get all the objects, application configurations, database scripts, and plug-ins together for deployment and review any changes that have been made to objects.
In the Prepare Deployment step, you can:
The Prepare Deployment step compares the objects in the application in your current environment to the target environment. Learn more about package comparison.
Your Prepare Deployment workflow depends on what you want to deploy:
If your application is new to the target environment, you can either deploy the entire application or deploy a package. This initial deployment will always include the application configurations needed to ensure a smooth deployment to your target.
If your application already exists in the target environment, select the corresponding option to continue:
|Deploy a package||Select this option to deploy the entire application or deploy a package. With this option you can deploy a package with objects, application configurations, database scripts, and/or plug-ins. A package can contain any or all of the contents listed.|
|Deploy only database scripts and plugins||Select this option to deploy database scripts or plug-ins without a package. With this option, you can add database scripts and plugins to the deployment. This functionality is only available through the compare and deploy workflow.|
Deployment of an entire application always includes the application configurations.
To prepare an entire application for deployment:
Learn how to create a package.
To prepare a package for deployment:
When you add items to, or remove items from, a package during the Prepare Deployment step, Appian saves those changes to the original package.
Application configurations are a category of settings that apply to the application on a global level. These configurations are not design objects, but may rely on design objects to function. Learn more about application configurations.
The deployed package always includes application configurations that you cannot remove during compare and deploy if either of the following is true:
However, if you're deploying a package for an application that already exists in the target environment, you can do any of the following during compare and deploy:
When you add or remove application configurations from a package during compare and deploy, Appian saves those changes to the original package.
If you're done working with application configurations, click NEXT to continue to the Inspect Deployment step.
Database scripts and plug-ins can be deployed on their own or included within the deployment of an application or package.
Database scripts and plug-ins are not exported along with packages and application objects, so skip this step if you do not have permission to deploy directly to the target environment.
Learn how to add database scripts to a package during development.
To deploy database scripts:
Any database scripts you added to the package during development will be present in this list.
When you add or remove database scripts during the Prepare Deployment step, Appian saves those changes to the original package.
For information on using database scripts and record types with sync enabled, see force sync on import.
Appian must be able to successfully run the scripts before it can attempt to deploy the objects. If an error occurs during script execution, the deployment will stop. To resolve script errors, refer to the deployment log for further details.
Deploying plug-ins with a package is only necessary under specific conditions. Learn more about these conditions before continuing.
To deploy plug-ins:
During inspection, Appian checks the items of your package for security warnings, failing test cases, and missing precedents. This step eliminates most manual checks and helps you to identify and resolve issues with the objects in your package.
Inspection only applies to Appian objects, application configurations, and the import customization file. Database scripts and plug-ins should be reviewed separately before deployment. Note that if a database script or plug-in fails during deployment, Appian will attempt to rollback changes. For more information on resolving problems with your deployment, see the deployment log.
To inspect your package for deployment:
Warnings are informational and are simply meant to call attention to potential issues before deployment. Warnings will not block your deployment.
Your deployment is almost ready to go. Just review a few high-level details to confirm that this is the information that you want displayed in the deployments view in the target environment and you're ready to deploy.
At this point, your workflow depends on your security and infrastructure:
To complete your direct deployment:
(Optional) Click Download Package to download the deployed package.
The downloaded package contains any design objects and application configurations that you selected for deployment. The download does not include any database scripts or plug-ins that you associated with the deployment. In addition to the package, you can download an import customization file.
A confirmation dialog will appear once the deployment has been sent to the target environment.
Once your deployment is in progress, the deployment details will be available on the deployments view of both the source and target environments. Deployment details are only visible to system administrators and application administrators.
If your deployment requires review, application administrators and users in the reviewer group will receive an email about the pending deployment. They can approve or reject deployments in the deployments details view.
To export the design objects and application configurations you selected and evaluated for deployment:
Click Download Package.
The exported package contains only design objects and application configurations selected for deployment. The export does not include the database scripts or plug-ins associated with the deployment.
Once a package has been successfully deployed, you can reuse it for another environment. This is helpful for deploying packages to higher environments after testing your changes in a lower environment. The same set of changes will be applied to ensure that you are making consistent updates across all of your environments.
This option is available to system administrators and application administrators for any completed, incoming deployments. The same objects and database scripts (in the same order) that were originally deployed will be used for the new deployment, but you can update the import customization file.
To reuse a successfully-deployed package:
Under ACTION, click DEPLOY TO ANOTHER ENVIRONMENT.
Inspection of a reused package checks the objects and application configurations in your package for missing precedents only.
Click DEPLOY. A confirmation dialog will display once the deployment has been sent to the target environment.
For system administrators and application administrators, deployment details will be available on the deployments view of both the source and target environments. To access the view quickly, click View Deployment Details in the confirmation dialog.
If your deployment requires review, reviewers will receive an email about the pending deployment
Appian has native deployment APIs that can be called from external tools, such as Jenkins. There are five endpoints that allow you to inspect and deploy packages, import customization files, and database scripts.
These APIs allow you to programmatically trigger deployments and integrate your Appian release into an automated pipeline. You can set up your pipeline once and run it the exact same way for all future deployments, saving time and avoiding manual errors.
In order to programmatically deploy Administration Console settings or tightly integrate with a version control system to store and retrieve package files, use the Automated Deployment Manager. For more information on setting it up, see the DevOps Quick Start Guide.
You can manually export a package from the source environment and then import it into the target environment. Import and export details are available in the deployments view of every environment.
Appian recommends using manual export and import if you do not have connected environments added to your infrastructure. To deploy objects, application configurations, plug-ins, import customization files, and database scripts directly to another environment, connect your environments and use compare and deploy.
You can include additional items in your packages for manual export and import. These items include:
However, other dependencies, such as changes to Administration Console settings, database scripts, and plug-ins, must be handled separately.
All manual imports occur asynchronously. This means that Appian queues your import as a background process, allowing you to continue development in Appian Designer while the system processes the import. You can review the status of your import from the deployments view and an email will be sent when the import completes.
Once you've checked your application for missing precedents, you're ready to export your package.
When you export an application, the exported package includes application configurations and all associated objects. In addition to the package, you can optionally download an import customization file.
To export an application:
You can also download an application in the application view by selecting Export Application in the settings menu .
An exported package can contain any design objects or application configurations you've added to the package. However, the exported package doesn't include database scripts or plug-ins you've added to the package.
To export a package:
Exported packages will be automatically deleted after 30 days and will no longer be available for download as attachments. You can change the number of days before export package cleanup in the Admin Console Settings.
Since you can't undo an import, you should always inspect a package before completing the import to check for warnings or missing precedents. At the same time as inspecting the package, you can also review the status of package items compared to those items in the target environment.
Importing a package at the environment level adds the objects to the specific application.
Importing an application into another application will add objects to that specific application. You can remove them by selecting the imported objects and clicking REMOVE FROM APP in the toolbar.
If the package you're importing includes design objects or application configurations that already exist in the target environment, the imported version overwrites the existing version.
To inspect and import a package:
An exported package contains design objects and application configurations only. The export doesn't include database scripts or plug-ins you've added to the package during development.
To export packages from different applications:
The IMPORT option in the applications list handles packages with multiple applications. When your import contains multiple packages, Appian adds the corresponding objects and application configurations to the appropriate applications in the target environment.
Developers with viewer access to an application and objects are able to create, compare, and inspect packages across environments, and manually export them. Application administrators and system administrators on the source environment are the only roles able to directly deploy to the target using compare and deploy.
Before using compare and deploy, a system administrator account must be specified when setting up deployment configuration in the administration console. The Deploy As account must be in the service account role.
When manually importing a package, you must ensure that you can administer the application and the objects that it contains:
The Last Modified By field displays the user who most recently modified the object and the time at which it happened. If the object supports versioning, the Last Modified By information of previous versions are not affected.
Best Practice: Regardless of deployment method, we recommend using a group for each application called
When objects are deployed to another Appian environment, the deployed objects contain a reference to the users and groups listed in their rolemaps. For example, an exported Knowledge Center contains the list of users and groups with rights to the Knowledge Center.
Rolemap deployment rules:
If an object already exists on the target environment (an object exists there with the same UUID), then:
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 has not been updated yet.
During deployments that include a record type with sync enabled, the record type must successfully sync in that 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. For more information on record types with sync enabled, see Data Sync in Appian Records.
When deploying database scripts that add rows to the source table of a record type with sync enabled, you can use the force sync command in the import customization file to see the new rows from your source directly after import. The record type does not need to be in the deployment package in order to force a sync. Instead of forcing a sync, you can also wait for the next scheduled sync of the record type or trigger a manual sync on the record type object directly.
To force the sync on import:
recordType.<UUID>.forceSync = true.
<UUID>with your record type's UUID.
To find your record type's UUID:
For more information on record types with sync enabled, see Data Sync in Appian Records.
On This Page