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 | 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 type of changes you have - whether it’s one or more applications, patches, environment specific data, Admin Console settings, or a mix. There are three methods for deploying a package in Appian:
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.
Appian recommends that production deployments be performed during off-peak hours. A maintenance window can be scheduled in the Administration Console, if necessary. Also, consider adding a post-deployment process to your application to automate any 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:
Compare and deploy is the easiest and recommended method of deployment. If your DevOps infrastructure is set up, these connected environments can be enabled 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:
After changes have been made, comparing objects between environments will help clarify which objects should be added to your package, making it easier to peer review and deploy.
Review your changes and add the necessary objects.
Database changes can be deployed alongside object changes:
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 force 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, uncomment the command recordType.<UUID>.forceSync = true
in your import customization file and replace <UUID>
with your record type’s UUID. You can find the record type object UUID by clicking the gear menu > Properties. For more information on record types with sync enabled, see Data Sync.
Select plugins to deploy alongside object changes:
If you have attached database scripts to your direct deployment, they can be downloaded from the deployments view and the deployment log will record any errors encountered during script execution.
The package must be inspected against the target environment before deploying it. Only packaged objects are inspected.
During inspect, Appian will provide you with warning messages about your packaged objects. There are four types of warnings that you should resolve before deploying your applications:
Once you resolve the issues, click Inspect Again to confirm that there are no additional missing precedents, warnings, or errors before clicking Next.
Inspect does not detect all possible errors. Plug-in errors, duplicate object names, other users editing the object, and missing import customization files are some issues that can cause import or deployment failures but are not reported when inspecting objects. Database scripts are not inspected and should be reviewed separately.
Confirm the high-level details, and add a name and description for the deployment. These allow you to track what’s included in a deployment, and will be reflected in the deployment details in the deployments view.
Click Deploy to send a deployment request to the target environment. You can also click Export to download the package as a zip file; this will not affect the target environment. Only application administrators can deploy, while viewers and editors can export objects to which they have permissions. Refer to the security section for more details.
A confirmation dialog will appear once the changes are sent to the target:
Once your deployment is in progress, the deployment details will be available on the Deployments View in the source and target environment. Deployment details are only visible by system administrators and application administrators.
If your deployments require review, application administrators, and users in the reviewer group will receive emails about the pending deployment. They can approve or reject packages in the deployments view. Once a package has successfully deployed to the target environment, the same package can be deployed to another environment as well.
Appian provides the Automated Deployment Manager which allows you to customize and even further automate your deployment process with Appian, by integrating with your team’s version control system and continuous integration tools.
For more information, see the DevOps Quick Start Guide.
Packages can be manually exported from the source environment and then imported into the target. 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 environments added to your infrastructure. To deploy objects, plug-ins, import customization files, and database scripts directly to another environment, use compare and deploy.
Import customization files can be included in your packages for manual export and import, but other dependencies will have to be handled separately. Administration Console settings, database scripts, and plug-ins must be exported and imported separately.
Once you've checked your application for missing precedents, you are ready to export your 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, conflicts, or missing precedents. Inspecting objects identifies general issues, such as missing dependencies, data stores that don't match the schema on the target environment, and package corruption or invalid XML.
Inspect may not report some errors. Insufficient permissions, duplicate object names, other users editing the object, and missing import customization files are some issues that can cause import failures but are not reported when inspecting objects.
Importing a patch at the application level will not add objects to a specific application. You must re-import the patch inside the correct 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.
To inspect and import a package:
To export multiple patches from the applications list view:
The IMPORT option in the applications view handles both applications and patches for multiple applications. When you import a package that contains multiple patches, the corresponding objects are added to the appropriate applications, depending on where the patches were created.
It's a best practice to include data types created from web service definition languages (WSDLs) in your application or patch package before exporting it. If those data types are not included in your package AND they don't already exist on the target environment, they'll be listed as problems in the inspection results. Data types that are normally created by the Call Web Service Smart Service or webservicequery() function during import cannot be created by the package inspection process.
Developers with viewer access to an application and objects are able to compare and inspect these objects 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 <Application_Name>_Administrators
.
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.
Issues may be encountered for various reasons. For example, an error may occur when you are not an administrator of the object, or if you attempt to deploy a group with the same name as another group.
Best Practice: Inspect the package before deployment in order to identify issues ahead of time.
The deployment, including the export and import processes, does not stop when errors are encountered on specific objects.
However, a problem during the import of an object may cause the import of related objects to also fail. For example, a failure to create a group type during an import would cause the import of any groups of that type to also fail (Appian does not attempt to import these groups in this case).
If a group fails to be created during import, and the group exists in rolemaps for other objects - or is a member of another group - the other objects (or groups) will fail to import due to the missing precedent.
The deployment will completely stop when a database script cannot be executed. In this case, Appian will roll back all possible changes that have been executed so far - this will vary depending on your specific database server. Executing subsequent database scripts and deploying objects will not be attempted.
In each case an error occurs, Appian gathers and displays information on any problems after all objects in the package have been processed. Generally, you can do one of the following:
When using compare and deploy, a deployment log is generated. The log details the stages of your deployment - such as the sending and receiving of the deployment request, executing database scripts, and importing the objects - and whether they succeeded. Errors that occur during database script execution or object import are included here. For more information on object import errors, see below.
When manually importing, an import log is generated. Objects with import issues are placed in one of two sections at the top of the import log:
The following example illustrates the log entries that may be generated when an object reference is not included in the package, and is not present in the target environment.
In this instance, an imported process model listed an individual user for the assignment of an activity. We recommend using groups for assignments instead. Otherwise, ensure that the target environment has a user with the same username, prior to importing the application.
Additional sections in the import log include: