Overview

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.

Types of Packages

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.

The Packaging Process

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.

Create Your Package

Once you have finalized requirements for enhancing an application, create a corresponding package in Appian.

1. Within an application, click Packages.
2. Click Create.
3. Fill out the package details and click Create. When working in a development team, use Create and Add Another to quickly create multiple packages that correspond to your backlog.

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.

Modify Your Package

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.

Preparing for Deployments

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.

When deploying changes to a higher environment, such as a test environment, your deployment process should generally follow these steps:

1. Validate your application in the source environment.
2. Compare environments and modify your package if needed.
3. Inspect your package and resolve any issues.
4. Deploy your package to the target environment.
5. Delete your package in the source environment.

Packages can also be manually exported from the source environment and imported in the target environment. To learn more, see this page.

Validate Your Application

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.

Compare Environments and Modify Your Package

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

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

• Changed:
  • This object was modified in the source environment and exists on the target environment.
  • This is the typical status you should expect when you make changes in a lower environment (development) and deploy them to a higher environment (test).
  • When you import, the object's definition will be updated in the target environment. The Last Modified information will be updated and the importing user will be set as the designer of any imported process models with this status.
• Conflict Detected:
  • This object was modified separately in both the source environment and the target environment.
  • This is the typical status you should expect when the object has different version histories, caused by one user making changes in a lower environment (development) and another user making changes in the higher environment (test) separately.
  • Make sure you address all objects with conflicts before importing your package. Otherwise, when you import, the object's definition will overwrite the definition in the target environment. The Last Modified information will be captured and the importing user will be set as the designer of any imported process models with this status.
• New:
  • This object was created in the source environment, but does not exist on the target environment.
  • You will commonly see this status as you are building new functionality.
  • When you import, the object will be created in the target environment. The Last Modified information will be captured and the importing user will be set as the designer of any imported process models with this status.
• Not Changed:
  • This object was NOT modified in the source environment and exists on the target environment.
  • This status will typically appear when you manually package a full application.
  • When you import, the object's definition will not be updated in the target environment because there are no updates to make. The Last Modified information will remain the same as it was pre-import and no change will be made to the designer of any process models with this status.
  • There are two situations when there have been changes to an object, but Appian recognizes that there are no practical differences. In these cases, the object has a status of Not Changed:
    • An application's contents have changed, but the application itself has not. For instance, this occurs when an application on the source environment has more objects within it than the application does on the target; however, the application's properties such as security and actions remain the same.
    • An object was modified in the source environment and/or the target environment, but the object definition is still identical. When this happens for expression rules, interfaces, and decisions, Appian will report them as Not Changed. On import, Appian will synchronize the objects and update the Last Modified information. Since the definition was already the same, no functional changes are introduced.

• Status Unavailable:
  • This object exists on the target environment, but the system doesn't have enough information to determine whether there's a conflict, the object was changed, or the object was not changed.
  • This status will apply to packages exported from a version of Appian, such as 17.2 where the inspection status was not supported for that object type.
  • When you import, the object's definition will be updated in the target environment. The Last Modified information will be updated and the importing user will be set as the designer of any imported process models with this status.

Addressing Objects With Conflicts

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:

1. Merge the changes: Review the object across environments and consolidate the necessary changes on the source environment. Then test and deploy your package, containing the updated object, from the source to the target. This approach is best when combining changes from two environments, such as a new enhancement in Development and a bug fix in Test.
2. Proceed with deployment: Overwrite the changes in the target environment. This approach should only be taken when the changes in the target are outdated and can be safely overwritten. For example, this can happen when the change in Test has already been made manually in Development.

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:

• For conflicts in an expression rule or interface's expression definition, resolve them by merging the changes directly on the object comparison view. This is most useful when each conflict in the object is a distinct change, such as a single function, component, or line of text.
  • In compare and deploy, click on the Conflict Detected status to view the object comparison:
  • In the Definition section, click Edit to start making changes.
  • Choose the changes to pull from Test to Development. Once all relevant changes are pulled in, save the newly updated object on the source environment and test it thoroughly to ensure that all changes work together.
  • Now the object in Development has all necessary changes, enabling a clean and safe deployment that overwrites the outdated object in Test.
• For more complex conflicts or conflicts in other objects, resolve them by editing the object and manually merging in relevant changes. It is a best practice to always resolve conflicts in the Development environment and deploy the updated object to Test. Below are guidelines for the general types of conflicts and how to address them, once you know which changes you’d like to keep.

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.

Inspecting Packages

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.

Deploying 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.

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.

Deleting Packages

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.