This page is about the packages you can create and deploy in Appian.
A package is a collection of Appian application changes that a developer 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.
We recommend that you use packages as a tool for building your applications and ensuring successful deployments. With packages, your development team can better organize the changes being introduced, collaborate effectively during development and peer reviews, and monitor the progress of each package periodically.
With packages, you can take advantage of direct deployments and external deployments.
Packages allow you to:
Your package may require other files to successfully deploy in the target environment. Import customization files, database scripts, and plug-ins are common dependencies that can be directly deployed alongside your packages. Based on the type of changes you are making to the target environment, your list of dependencies and how you deploy them will vary.
The packaging process includes the following steps:
Appian RPA customers need to package and deploy robotic processes separately from applications. Learn how to deploy robotic processes and apps.
You can configure the following properties for your package:
Property | Description |
---|---|
Name | The name of the package. This name must be unique within an individual application. |
Link to Ticket | (Optional) Add the URL of the related ticket in your project management tool (for example, Jira). This property enables better traceability between Appian and your project management tool. |
Description | (Optional) Add a clear, concise description of the application changes you're including in the package. This description helps you to quickly assess differences in packages. |
To make your development life cycle more streamlined and efficient, Appian recommends creating packages before making changes to objects. Create a corresponding package once you have finalized requirements for building or enhancing an application.
All packages created in an application will be visible to any user with Viewer permissions or above to the application. Within a package, users can only see the objects to which they have the required privileges.
You can create up to 100 packages for an individual application.
To create a package:
In the application view, click PACKAGES.
In the Packages dialog, click CREATE.
Configure the package properties.
For example:
In the package list, click the name of the package you just created.
You'll notice the contents view for the package is empty right now. Most likely, you'll want to do one or more of the following actions next:
While building or improving your application, you'll commonly perform the actions described in this section.
To view the list of packages for an individual application, click PACKAGES in the application view.
From this list, you can:
To view an individual package, select the package from the dropdown menu in the application view:
For example:
The package view includes:
You can easily share the link to a package for change reviews.
To get the link:
To edit package properties:
Once you've created a package, you'll want to specify the design objects to include in the package.
To add design objects to a package:
Continue as appropriate:
Make your selections:
Option | Action |
---|---|
Application Contents | Enter the name of the application, then select the application from the dropdown list. If you select an application other than (or in addition to) the current application, Appian first adds the objects from that other application to the current application, then adds the objects to the package. |
Folder Contents | Enter the name of a folder, then select the folder from the dropdown list. You can select multiple folders. |
Existing Objects | For each object category, enter the name of an object, then select the object from the dropdown list. Object categories include Record Types, Process Models, Reports, and Other (for example, a connected system. |
(Optional) If checking for missing precedents:
You can add the contents of one package (source package) to another package (destination package). These contents include design objects and database scripts.
If the destination package already contains database scripts, Appian adds scripts from the source package and, by default, places them last in execution order.
To add contents from one package to another:
You can modify objects in the package view the same way you'd modify the objects in the applications view.
You can:
In the package list, you can add objects from one package to another.
Improving an application sometimes requires changes in the structure of underlying data sources. To implement these changes in the data source in a higher environment, you can create database scripts.
You can include these database scripts when you deploy a package. However, we recommend adding database scripts to the package during development. Adding scripts to packages lends itself to better maintainability and collaboration with your teammates throughout the development life cycle, because with packages you can track, add, reorder, and generally maintain the scripts as you develop.
When you add contents from one package to another, the contents include the database scripts associated with the original package.
To add a database script to a package:
Configure the following properties:
Property | Description |
---|---|
Data Source | Select the relational database that stores data for this application. |
Database Scripts | For each database script you want to add:
The uploaded script displays in the scripts table. Appian executes the database scripts in the order in which they appear in this table. |
For example:
To update database scripts in a package:
To delete database scripts from a package:
We recommend using compare and deploy to streamline your package deployment.
Compare and deploy allows you to:
You must add environments to your infrastructure to use compare and deploy.
When deploying changes to a higher environment, such as a test environment, your deployment process should generally follow these steps:
Make sure that all necessary objects are in your application by running missing precedents. It is also a best practice to review the security summary and make sure all your objects have the appropriate security set before beginning the packaging process.
Comparing objects across environments allows you to review objects in your package and confirm that you are deploying the correct changes to the target environment. Comparing objects in a package is only available if you have added environments to your infrastructure.
If you manually create and export your package, you will have an opportunity to review the object comparison statuses by inspecting your package during manual import in the target environment.
Object comparison statuses are available when you compare objects across environments or inspect packages before import. These statuses are helpful for understanding how your objects differ between a source and target environment, as well as how they will be handled during deployment. You should use the statuses to confirm that the correct objects are in your package and detect any conflicts before continuing with a deployment.
Status | Object Exists in Target Environment | Object Will Be Imported |
---|---|---|
Changed | Yes | Yes |
Conflict Detected | Yes | Yes |
New | No | Yes |
Not Changed | Yes | No |
Status Unavailable | Yes | Yes |
If you need to force an import for objects with a Not Changed status, add the FORCE_UPDATE
import-specific setting to your import customization file. See Managing Import Customization Files for more information on when and how to force an update.
Conflicts may occur when an object is modified in the target environment and modified separately in the source environment. Objects with the status of Conflict Detected will be displayed when comparing objects across environments when using compare and deploy or when inspecting a package before manual deployment.
When you see this status, pause your deployment and proceed carefully since there is a chance of overwriting someone else's work. Examine the Last Modified information for clues about who else made a change to the object and when. If possible, talk to the teammate who made the change in order to understand what changes they made and why.
Depending on the results of this investigation, choose an option to move forward with:
We will explore the different ways to accomplish the first option and merge your changes, using the above example of deploying from Development to Test:
Conflict Type |
Resolution Steps |
---|---|
Expression and text fields |
In the object comparison view, copy the desired expression or text from the object on Test. Then open the corresponding object on Development and paste in the copied text. |
Selection fields, such as checkboxes |
Open the object in Development and choose the selections to match the desired configuration in the object comparison view. |
Smart services in process models |
|
Documents |
Download the desired version of the document from Test, then upload it as a new version of the document on Development. |
The object's status may still appear as Conflict Detected until you deploy. However, this method prevents future flagged conflicts when comparing the object across environments.
After creating your package, it is a best practice to inspect the objects before deployment. This ensures that no unexpected changes have been made to the target environment and detects potential conflicts or import errors early.
Compare and deploy automatically inspects your package after you finish preparing it. If you do not have environments added to your infrastructure, you can also inspect your package before import in the target environment. As with all deployment activities, for production environments we recommend running inspections during off-peak hours.
The inspection results summarize which objects in your package have problems or warnings, how many will be created or updated by import, and how many will be skipped. When run in the target environment on a manually exported package, this summary also includes detailed information about the status of each object in your package and when they were last modified in the target environment.
Inspect only applies to Appian objects and the import customization file. Database scripts and plug-ins should be reviewed separately.
Deploying a package is the goal of your packaging process. With compare and deploy, you can let Appian send your package to the target environment, as long as the target is configured to allow direct deployment. Alternately, you can download the package zip file and deploy it yourself by logging in to the target environment and manually importing it. Learn more about manual export and import of packages.
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. The application view allows you to check your application for missing precedents and add them to the application. You can track deployment progress in the deployments view.
Learn more about the deployment process.
Learn how to deploy your packages.
Learn more about object-specific rules that apply to deployments.
For auditing purposes, you can always find all changes introduced to an application in the deployments view.
It is a maintenance best practice to delete packages when they are no longer needed.
After successful deployments, we recommend that you delete successfully deployed packages from applications in your source environment. This allows you to keep your applications clean, so long-running or unused packages don't build up over time. If your team works in sprints, you can also delete multiple packages in bulk at the end of each sprint or release.
Deleting a package does not delete the objects associated with the package.
To delete a package: