Prepare Deployment Packages

Overview

This page is about the package process and the types of packages you can create and deploy in Appian. Creating packages is a part of the deployment process, and should be taken into consideration while you are building applications to ensure that your changes will be deployed successfully.

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

There are three different types of packages that you can deploy in Appian. In most cases, your packages will contain application objects, but can also include environment-specific information, such as import customization files or database scripts.

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

  • Patches contain new or updated objects, which a developer deploys when introducing an update to an existing application in the target environment. Patches are helpful for deploying bug fixes or enhancements.

  • Administration Console Settings contain updates to your Administration settings, such as site branding or third-party credentials in the target environment.

Your package may include dependencies that are required to successfully deploy updates to your application. Import customization files and database scripts are common dependencies that can be packaged with applications or patches. Your package may also rely on plug-ins or other dependencies that must be deployed before you start a package deployment. Depending 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

There are two ways you can create packages in Appian: using compare and deploy to automatically identify changed objects or assembling your changes manually. To make your deployment process more efficient, compare and deploy is the recommended approach. Compare and deploy allows you to compare objects across environments, bundle database scripts and import customization files with your package, and inspect your objects before directly deploying your package 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 packaging process should generally follow these steps:

  1. Validate your application in the source environment.
  2. Compare environments and prepare your package.
  3. Inspect your package and resolve any issues.
  4. Deploy your package to the target environment.

Validate Your Application

Make sure that all necessary objects are in your application by running missing precedents. Both methods of creating packages start with the objects in an application. 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 Prepare Your Package

Comparing objects across environments allows you to review changes as you're packaging them and confirm that you are deploying the correct changes to the target environment. Comparing objects during package preparation 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 compare objects by inspecting your package upon 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 in the source environment and separately in the target environment.
    • This is the typical status you should expect when you make changes in a lower environment (development) and a user made 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, rather than a patch of changes. Compare and deploy automatically filters out Not Changed objects.
    • 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.

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.

  • 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 or when inspecting a package before manual import. This status is helpful when deploying between multiple development environments. When you see this status, you should pause your deployment and proceed carefully since there is a chance of overwriting someone's work.

When you encounter unexpected conflicts you can further investigate as follows:

  • If you are using compare and deploy, view the differences for the object with the Conflict Detected status by clicking the status link. compare conflict detected
  • If you are inspecting before manual import, examine the Last Modified in This Environment information for clues about who might have made a change before you. If possible, talk to the user who made the change in order to understand what changes they made and why. Also consider which environments these changes have been made in. For example, if it is a process model, are there running instances to consider in production?
  • Depending on the results of this investigation, choose an option to move forward with:
    1. Proceed with deployment and overwrite the changes in the target environment.
    2. Deploy changes from the target environment to the source environment by using compare and deploy or manual export. Then create an updated package in the source environment.
    3. Update the object in the source environment with the appropriate changes, then build and export an updated package. Note: The objects will still appear in the Conflict Detected status, but the manual merge means you won't be overwriting changes.

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.

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 Application

Inspect only applies to Appian objects and the import customization file. Database scripts and plug-ins should be reviewed separately.

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.

For instructions on how to deploy packages, see this page.

For more information about object-specific rules that apply to deployments, see this page.

Open in Github Built: Fri, Mar 11, 2022 (04:59:07 PM)

On This Page

FEEDBACK