Deployment

Note:  This feature is currently in beta. There could be changes to its design, behavior, and functionality in upcoming releases.

Deployment is the process of moving resources from one tenant to another. It’s commonly used as part of an application lifecycle management (ALM) practices to ensure software is properly tested before being deployed.

In Nintex Apps deployment is handled by creating deployment packages. Once a package is created, it is stored and shared between all connected environments.

Connected environments are managed outside of Nintex Apps. The number and name of your environments depends on your subscription; contact your Nintex representative for more information about your entitlements. For more information about environments, see Environments.

Note:  This topic only covers the deployment UI available in Nintex Apps. It doesn’t account for the features discussed in the Configure workflows topic or the functionality provided by the command line interface—which is meant for advanced deployment use cases.

Deployable resources

When a deployment package is created, apps and their pages, connections, app permission sets, and other resources are bundled into the package file.

It’s also possible to bundle other Nintex resources used within an app, including:

An app’s associated resources are managed through the app’s detail screen. Ensure all expected resources are listed when creating an app package.Nintex Apps attempts to keep track of app dependencies, like connections used in pages, but it may not detect some advanced resource usage—like workflows called from other workflows.

Each package’s bundled resources can be viewed within the Contents tab of the package detail modal.

Managing packages

Each deployment package has the following metadata, which is configured when the package is created:

  • Package name: The builder-facing label for the package, for example Marketing Dashboard

  • App: The app (and all related resources) to package

  • Release notes: A builder-facing description of the deployment package, meant to provide a summary and useful information about the purpose and state of the app within the package. Also useful for future versions of already deployed applications, allowing a space to document new features included in a newly created package.

  • Scope: Determines which environment the package is available to be installed into. Some packages may only be intended for a single environment, such as testing a new package in a development environment. In these instances, consider selecting Local.

    However, for packages that are being deployed as part of an ALM process, selecting All environments allows the package to be installed in any connected environment.

    Important:  A package’s scope cannot be changed once it’s created.

Once a package is created or imported, additional information is made available in the package details modal. The Contents tab lists the resources within the package and the History tab lists the creation and installation date of the package and who initiated those actions.

Package format

As Nintex Apps continues to develop, the structure of deployment packages may change over time. To account for this, each package’s format version is listed in the package’s details.

If a package is an older format, it may contain incompatible features and may not be able to be installed within a connected environment. If a package cannot be installed, the Install button is disabled and a message appears.

To resolve this, the app and its resources must be repackaged in the source tenant.

Create a package

Before creating a deployment package, consider the following:

  • Once created or imported, deployment packages cannot be removed or deleted.
  • Deployment packaging is run in user context, meaning it is bound by the permissions of the user who created the package. If the running user does not have access to all app resources, for example a workflow used in an app, errors can occur. Consider having a highly permissioned user create deployment packages.
  1. Click Create.
  2. Fill out the deployment package details:
    • In addition to the app’s name, consider including a version identifier in the package name. This keeps package names unique, and helps keep track of apps as they are developed and deployed.
    • Packaged resources are based on the resources associated with the selected app.
  3. Click Create.

If the package’s scope is set to All environments, then the package is automatically available to all linked environments (i.e. develop, test, production) once it’s created.

Packages do not automatically update to include any recent changes or additional metadata. For example, creating a deployment package and later adding a new app permission set to that app would require creating a new package.

Packaging permission sets

As deployment packages only contain the resources for a single app, only the related app permission sets are included in the package.

If your app makes heavy use of site permission sets for user access, consider moving those permissions to app permission sets for smoother deployment experience. Otherwise, the missing site permissions may impact user access in the destination environment.

Download a package

  1. In the packages list, click the package to download. The package detail modal appears.
  2. Click Download.
  3. Select the desired download location on your machine.
  4. Confirm the download.

Install a package

Important:  Installing a package will overwrite any resources with names matching the contents of the deployment package. If these resources existed previously and you’ve made changes to them after creating the package, consider repackaging the app.

  1. In the packages list, click the package to install. The package detail modal appears.
  2. Click Install.
  3. Confirm the installation by clicking Install.

Import a package

If you’ve downloaded a package as a file on your machine, you can import that package via the deployment UI.

Note:  All imported packages are set to a local scope.

  1. In the deployment screen, click Import.
  2. In the upload area, drag the package’s ZIP file or click within the upload area to open the file browser.
  3. After selecting the package file, choose how you wish to import:
    • Import: The package is made available in the current environment for later installation.
    • Import and install: The package is imported and installed, allowing for immediate configuration of the imported app.

Install history

In the deployment screen, the Install history panel displays a history of all package installations within the environment. For each installation, the following appears:

  • Name of the package
    • Clicking View beside the package name opens its detail modal.
  • Installation date
  • The user that installed the package

Troubleshooting

I don’t see the deployment package in my environment

If you’ve created or imported a deployment package in one environment, but don’t see it in a different, connected environment, its scope may be set to local.

To make the package available to all connected environments, recreate or reimport the package and set its scope to all environments. Alternatively, if you know you need the package in only one environment, import the package to that environment set the scope to local.