Prepare the Deployment

The second step of a direct deployment using Compare and Deploy is the Prepare Deployment step. Here, you assemble all of the all the objects, application configurations, database scripts, and plug-ins across packages for deployment and review any changes that have been made to objects.

In the Prepare Deployment step, you can:

• Select an application, packages, or database scripts and plug-ins for deployment.
• See all objects within your application or packages.
• Manage the application configurations, objects, database scripts, or plug-ins in the deployment.
• View the statuses for application configurations, objects, and plug-ins.
• Review changes to objects.

The Prepare Deployment step compares the objects in your current environment to the target environment. Learn more about package comparison.

Choose what to deploy

Your Prepare Deployment workflow depends on what you want to deploy:

• If your application is new to the target environment, you can either deploy the entire application or deploy a package. This initial deployment always includes the application configurations needed to ensure a smooth deployment to your target.

• If your application already exists in the target environment, select the corresponding option to continue:

  Option	Description
  All Application Objects	Select this option to deploy the entire application. With this option you can deploy all objects in an application, as well as database scripts and plug-ins.
  Packages	Select this option to deploy a package. With this option you can deploy a package with objects, application configurations, database scripts, and/or plug-ins. A package can contain any or all of the contents listed.
  Database Scripts and plug-ins	Select this option to deploy database scripts or plug-ins without a package. With this option, you can add database scripts and plug-ins to the deployment. This functionality is only available through the Compare and Deploy workflow.

Prepare an application

Deployment of an entire application always includes the application configurations.

To prepare an entire application for deployment:

1. Under What would you like to deploy?, select All Application Objects.
2. Review the contents of the application:
   • Click on the status of objects or application configurations for more information.
   • Resolve issues as needed.
3. (Optional) Add database scripts or plug-ins.
4. Click NEXT to continue to the Inspect Deployment step.

Scroll or drag to pan · ⌘+/⌘− to zoom · Esc to close

Prepare a package

Learn how to create a package.

To prepare one package from a single application for deployment:

1. Under What would you like to deploy?, select Packages.
2. Select your package from the Select packages dropdown list.
   • For new application deployments, application configurations are included in the deployment by default. For all future deployments you can choose whether to include them using the Include app configurations in this deployment toggle. See the Application configurations section for more information.
3. Review the contents of the package:
   • Click on the status of objects, application configurations, or plug-ins for more information.
   • Resolve issues as needed.
4. (Optional) You can remove design objects from the package:
   • In the objects grid, select an object.
   • Click REMOVE FROM PACKAGE.
5. (Optional) You can add design objects to the package:
   • Toggle off Only view objects in package. The objects grid updates to display all objects in the application.
   • In the objects grid, select the object(s) you want to add.
   • Click ADD TO PACKAGE.
6. (Optional) Add or remove application configurations.
7. (Optional) Add database scripts or plug-ins.
8. Click NEXT to continue to the Inspect Deployment step.

Modify package contents

You can only modify the contents of a package if it is the only package being deployed for that application.

Meaning, you can only add or remove package contents when:

• You deploy a single package.
• You deploy a single package per application.

To quickly figure out if you can modify package contents, check to see if there is a checkbox beside the object name in the Objects tab of the Prepare step in Compare and Deploy.

Add or remove application configurations

Application configurations are a category of settings that apply to the application on a global level. These configurations are not design objects, but may rely on design objects to function. Learn more about application configurations.

The deployment always includes application configurations that you cannot remove during Compare and Deploy if either of the following is true:

• Your application is new to the target environment.
• You're preparing to deploy the entire application to the target environment.

However, if you're deploying packages for an application that already exists in the target environment, you can do any of the following during Compare and Deploy:

• If the status of the application configurations is Changed or Conflict Detected, click View Details to review the current application configurations compared to the configurations present in the target environment.
  • Added configurations are highlighted in green.
  • Deleted configurations are highlighted in red.
  • Collapsed sections contain unchanged configurations. You can click sections to expand them.
• Toggle on Include app configurations in this deployment to add application configurations to the deployment and associated package.
• Toggle off Include app configurations in this deployment to remove application configurations from both the deployment and the package.

If you're done working with application configurations, click NEXT to continue to the Inspect Deployment step.

Add or remove database scripts

Database scripts can be deployed on their own or included within the deployment of an application or package. You can specify the data source and database scripts for each package in the deployment. This means that a single deployment can have multiple database scripts and multiple data sources.

You can set the execution order of database scripts within a package and reorder the execution order of packages. This gives you complete control over the order that the database scripts are executed for your deployment. The execution order of database scripts within a package is saved to the package, but the execution order of packages is not persisted.

Database scripts are not exported along with packages and application objects. Skip this step if you do not have permission to deploy database scripts directly to the target environment.

Add or remove database scripts from a package

To add database scripts and data sources to a deployment:

1. Click DATABASE SCRIPTS.
2. Select a Data Source for the app or each package. If you added database scripts to the package during development, this field automatically selects the data sources for those database scripts.
   • If a data source connected system is a part of your deployment, the associated data source will not display in the list. You must deploy database scripts separately from their connected system.
3. Click UPLOAD to add a database script.
4. In the Database Scripts list:
   • To remove scripts, click next to the script in the list.
   • To change the execution order of database scripts in a package, drag and drop the database scripts into the correct order. To change the overall execution order of packages, use the order arrows next to the box for each package.
5. Click NEXT to continue to the Inspect Deployment step.

If you're deploying a database script that changes a database related to a record type with sync enabled, the deployment may require an import customization file (ICF) to trigger a sync after deployment of the script in the target environment. Learn more about triggering a sync in the target environment.

Appian must be able to successfully run the scripts before it can attempt to deploy the objects. Scripts for all packages are executed before any objects are deployed. If an error occurs during script execution, the deployment stops. To resolve script errors, refer to the deployment log for further details.

If you are deploying a generated package created for a release in an intermediate environment, you can learn more about deploying multiple database scripts for generated packages.

Save database scripts to a package

When you add or remove database scripts during the Prepare Deployment step, Appian saves those changes to the associated package.

The execution order of database scripts within a package is also saved to the package.

Add plug-ins

Plug-ins can be deployed on their own or included within the deployment of an application or packages.

Deploying plug-ins with a package is only necessary under specific conditions. Learn more about these conditions before continuing.

Plug-ins are not exported along with packages and application objects. Skip this step if you do not have permission to deploy plug-ins directly to the target environment.

To deploy plug-ins:

1. Click PLUG-INS. By default, the grid displays plug-ins that have been added to the packages during development.
2. (Optional) Filter the grid by selecting a status from the dropdown list.
3. Verify that the package includes the referenced plug-ins you want to be included. To do this, compare the Show plug-ins in package list to the Show plug-ins referenced in package list. By default, the referenced plug-ins list shows plug-ins with a Changed or New status only.
4. Add referenced plug-ins to the package:
   • Select Show plug-ins referenced in package.
   • Select one or more plug-ins in the referenced plug-ins list.
   • Click ADD TO PACKAGE.
5. Add unreferenced plug-ins to the package:
   • Select Show plug-ins in environment. The grid displays all plug-ins installed in the current environment.
   • Select one or more plug-ins in the list.
   • Click ADD TO PACKAGE.
6. Remove plug-ins from the package:
   • Select any grid display option.
   • Select one or more plug-ins in the plug-ins list.
   • Click REMOVE FROM PACKAGE.
   

   Scroll or drag to pan · ⌘+/⌘− to zoom · Esc to close

7. Click NEXT to continue to the Inspect Deployment step.

Comparing across environments

This section describes how Appian compares objects across environments. By comparing the objects in your deployment to those same objects in the target environment, you can review your objects and confirm that you are deploying the correct changes to the target environment.

In both direct deployments and inspect before import, Appian compares objects and application configurations included in the package to the existing applications in a target environment. This allows you allows you to review your packages and confirm that you are deploying the correct changes to the target environment.

In direct deployments only, Appian also performs the comparison for any plug-ins included in the package.

What is compared

Package contents can include design objects, application configurations, database scripts, and plug-ins. Appian compares the packages' contents to the existing versions of those contents in the target environment when you do either of the following:

• Prepare the package as part of direct deployment (only available if you have connected environments in your infrastructure)
• Inspect the packages as part of a manual import.

This comparison determines if the items in the packages you're deploying:

• Exist on the target environment.
• Exist on the target environment and have changed.
• Exist on the target environment but have conflicts with those in your source environment.

Appian displays a comparison status for each item in the packages during the Prepare Deployment step of compare and deploy and when you inspect the package. You can use the status to confirm that your packages include the correct items and detect any conflicts before continuing with a direct deployment or import. Additionally, in compare and deploy, you can immediately view the differences between the items in the packages and the target environment.

Comparison statuses

Comparison statuses are helpful for understanding how items in an incoming package differ from existing items in the target environment, as well as how the package items will be handled during deployment.

These statuses include the following:

Status	Item Exists in Target Environment	Item Will Overwrite on Import
Changed	Yes	Yes
Conflict Detected	Yes	Yes
New	No	Yes
Not Changed	Yes	No1
Protected	Yes	No1
Status Unavailable	Yes	Yes

¹ Use an import customization file to force import of unchanged objects or override object protection.

Changed

• The design object or plug-in was modified in the source environment and exists on the target environment.
• This status will typically appear when you make changes in a lower environment (development) and deploy them to a higher environment (test).
• When you import, Appian updates the definition of the object, application configuration, or plug-in in the target environment. The Last Modified information will be updated. Also, the importing user will be set as the designer of any imported process models with this status.

Conflict Detected

• The design object or plug-in was modified separately in both the source environment and the target environment, or the application configurations were modified in the source environment and exist on the target environment.
• This status will typically appear when the version histories the incoming item and the existing item differ. This condition is 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 conflicts before importing your package. Otherwise, when you import, the package item'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

• The package item 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 package item will be created in the target environment. The Last Modified information will be captured. Also, the importing user will be set as the designer of any imported process models with this status.

Not Changed

• The package item was not modified in both source and target enviroments.
• This status will typically appear when you manually package a full application.
• When you import, the package item'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. No change will be made to the designer of any process models with this status.
• There are two situations when changes have been made to an object, but Appian recognizes that there are no practical differences. In these cases, the object has a status of Not Changed:
  • Design objects in an application have changed, but the application configurations have not. For instance, an application on the source environment might contain more objects than the application does on the target; however, the application configurations remain the same.
  • A design 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.

Protected

• The package item was edited in the target environment as part of an expected and supported workflow. The changes from the source environment will be skipped.
• In most applications, making changes to objects in a target environment is unwanted behavior, because objects from the source environment are the most up-to-date, authoritative version of the objects. However, an application can incorporate capabilities that let business users create and edit certain objects in a target environment. For example, reports and dashboards in Process HQ can be modified by business users after deployment. In this workflow, the Protected status prevents the automatic overwriting of the business user's changes in the target environment.
• This status is only assigned if objects of this type have been edited by business users in the target environment. If an object of this type has not been edited in the target environment when you deploy from a source environment, the system assigns the object the other standard statuses. For example, you can change a report in the source environment, then deploy it to a target environment where the object has not been edited, and the system will assign a Changed status instead of Protected.

Status Unavailable

• This package item exists on the target environment, but the system doesn't have enough information to make a comparison.
• 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 deploy or import, the package item's definition will be updated in the target environment. The Last Modified information will be updated. Also, the importing user will be set as the designer of any imported process models with this status.

View comparison results

In compare and deploy, you can view the differences between package items and items in the target environment if you click a Changed, Conflict Detected, or Protected status.

The comparison results open in a new browser tab. Values for the package item appear in the left column. Values for the item in the target environment appear in the right column. Sections that do not contain any changes are collapsed by default.

The differences between the items in each environment are highlighted with the following colors:

Difference	Color
Addition	GREEN
Modification	YELLOW
Deletion	RED

The comparison results are divided into sections. These sections contain properties specific to the type of object or configuration being compared.

The system applies object security and data security to the property values in the results, so you may see the following values display when appropriate:

Display Value	Condition
[Not visible]	You do not have permissions to access an object or related data from the target environment. For example, you might have access to a record type, but not to individual records associated with that object.
[Value masked] or (Target value masked)	The property potentially contains sensitive data from the source environment, so the value is hidden. For example, you might have access to a report that contains patient data in a medical setting, and business users might have configured a filter for that report that uses a patient name.

To better understand individual properties included in comparison results, see the descriptions of the object types or application configurations involved.

Addressing conflicts

Conflicts may occur when a package item is modified in the target environment and modified separately in the source environment.

When you see the Conflict Detected status:

1. Pause your deployment and proceed carefully since there is a chance of overwriting someone else's work.
2. Examine the Last Modified information for insight into who made a change to the object and when.
3. If possible, talk to the teammate who made the change in order to understand what changes they made and why.

Depending on what you find, choose either of the following approaches to moving forward:

• Merge the changes: Review the item across environments and consolidate the necessary changes on the source environment. Then test and deploy your package, containing the updated item, 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.
• 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, you might choose this option 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 application configurations during compare and deploy, resolve the discrepancy in the specified application configuration.
• For conflicts in application configurations during manual import, check the application configurations in each environment to identify which configuration is involved, then resolve the discrepancy.
• 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, item, or line of text.
  • In compare and deploy, click on the Conflict Detected status to view the object comparison:
  

  Scroll or drag to pan · ⌘+/⌘− to zoom · Esc to close

  • In the Definition section, click Edit to start making changes.
  

  Scroll or drag to pan · ⌘+/⌘− to zoom · Esc to close

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

  Scroll or drag to pan · ⌘+/⌘− to zoom · Esc to close

  • 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 in the same environment. Deploy the process model from Test to Development, which will create a new version of the process model on Development. 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.

Feedback