This page is about the packaging process and the types of packages you can create and deploy in Appian. Creating packages is an integral part of the deployment process and therefore you should use package management as a tool for building your applications and ensuring successful deployments.
For an overview about the deployment process, see Deploy Applications.
For more instructions on how to deploy your packages, see Deploy Packages to Target Environments.
Appian RPA customers need to package and deploy robotic processes separately from applications. Learn how to deploy robotic processes and apps.
A package is a collection of Appian application changes that a developer can deploy to another environment. You can use packages containing new and updated objects to enhance an application in the target environment via a deployment. 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.
In addition to deploying enhancements as described above, you can also use the following types of packages to deploy new applications and change administration settings in the target environment:
Applications contain a set of objects that make up a business solution. Applications should be used to introduce a new set of objects that do not exist in the target environment.
Administration Console Settings contain updates to your Administration settings, such as site branding or third-party credentials in the target environment.
Your package may require other files to successfully deploy updates to your application. 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.
To make your development life cycle processes more streamlined and efficient, Appian recommends creating packages before making changes to objects. Packages can have a name, description, and a link to a ticket for better traceability between Appian and your project management tool. 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.
Once you have finalized requirements for enhancing an application, create a corresponding package in Appian.
With packages, your team can better organize the changes being introduced, collaborate effectively during development and peer reviews, and monitor the progress of each package periodically. For an application, you can create up to 100 packages. It is a maintenance best practice to clean up packages and delete them when they are no longer needed.
You can make changes to objects from within a package. Use the package drop-down menu in your application's objects view to navigate to your package. This view allows you to focus only on the set of objects that you are working on as part of your enhancement for the application. You can create new and add existing objects to your package as needed.
You can easily share the link to your package for change reviews, by clicking Copy Package Link to copy the URL to your clipboard.
To modify the package name, description, or link to ticket, click more options > Edit.
Appian recommends the use of compare and deploy for a streamlined deployment of packages. Compare and deploy allows you to compare objects in a package across environments, bundle database scripts, plug-ins and import customization files, and inspect your package before directly deploying it to the target environment.
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:
Packages can also be manually exported from the source environment and imported in the target environment. To learn more, see this page.
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|
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||- If you want to copy an entire smart service, you can do this between process models on the same environment. Deploy the process model from Test to Development, which will create a new version of the process model on Development. You can now separately open the last two versions of your process model, one being the original version on Development and one being the version deployed from Test. Copy the smart service from the process model version that came from Test. In the original version from Development, paste it onto the canvas, connect the smart service to the appropriate flows, and Save & Publish this version as the latest. Make sure to test your changes before deploying the updated process model to Test.
- If you want to merge select configurations within a smart service, follow the above advice for expression, text, or selection fields.
|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.
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.
Deploying a package is the last step in 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 deployments. Alternately, you can download the package zip file and deploy it yourself by logging in to the target environment and manually importing it.
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.
For instructions on how to deploy packages, see this page.
For more information about object-specific rules that apply to deployments, see this page.
After successful deployments, it is recommended to 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.
For auditing purposes, you can always find all changes introduced to an application in the deployments view.
On This Page