Note: Nintex Apps data centers are located in West US and Australia (AUS). In-region processing of Nintex Apps data is only available in these regions.

CI/CD with Nintex Apps

CI/CD is an acronym that refers to the several development philosophies that, when combined, aim to automate large parts of application testing, code quality, and deployment. And while CI/CD principles are typically applied to products written exclusively in code, it's also possible to build a full CI/CD pipeline atop your Nintex Apps development processes.

• CI typically stands for continuous integration —where developers integrate application changes into a single, shared repository as often as possible. Each time a developer pushes code to this central repository, that code is then verified by an automated build, allowing teams to detect problems early.

• CD can stand for two separate concepts, but they are often used in conjunction:

  • Continuous delivery mandates work within the shared repository always be deliverable, which means automating many of the processes to test and package the software.

    • Automated testing occurs whenever code changes are pushed to a team's shared repository. This testing ensures that the application does not break when changes are made to its backend code.
    • Additionally, the packaging steps required to prepare or compile the software for release are typically included under the umbrella of continuous delivery.

  • Continuous deployment is an additional, automated software shipping strategy wherein the tested and packaged application is deployed as often as needed. The frequency of these deployments varies based on the needs of the organization.

Each of these philosophies can be implemented into an organization's larger application lifecycle management (ALM) process. These philosophies have gained traction in many modern software development circles because they emphasize code quality and ease of deployment—two of the biggest concerns in building sustainable, effective application development. CI/CD is especially important when developing apps as a team. CI/CD ensures that everyone's changes are incorporated into the same place, while automated testing verifies quality. Teams work faster and better together.

Where does this come in for Nintex Apps ? Nintex Apps's apps are composed of various metadata objects which contain the configurations that Nintex Apps processes to display those applications. By understanding the anatomy of your applications, you can store these metadata objects in source control and create CI/CD processes around them.

Prerequisites

Get cross-team buy-in

Implementing CI/CD can be a complicated process that requires the effort and buy-in of multiple teams. It is difficult, and often inadvisable, to do without cross-team cooperation. Because of the variety of tools and skills needed, consider assembling a cross-functional team to implement CI/CD for your Nintex implementations.

Make informed application lifecycle management choices

Application lifecycle management (ALM) can take many forms. CI/CD is often a more programmatic approach, and it may not fit the needs of your organization or your Nintex deployment strategy (i.e. Nintex Apps vs the Nintex extension on Salesforce).

• For more on a declarative ALM in the context of Salesforce, see Salesforce's Trailhead lesson on the subject.
• For a programmatic approach to Salesforce application deployment, familiarize yourself with the concepts and tools within Salesforce DX.

Learn the skuid CLI

The CLI is the primary means of retrieving and deploying almost all Nintex Apps metadata on both Nintex Apps and Salesforce. If you haven't already done so, familiarize yourself with the CLI.

If you'll be working within a Salesforce environment, it's also advisable to learn the Salesforce CLI, as it can be used to programmatically retrieve, package, and deploy Salesforce metadata.

Continuous Integration

Choose a shared repository system and hosting platform

One of the tenets of CI/CD includes choosing a single shared repository for an application's code—in Nintex Apps's case this means page XML and other metadata objects like connections. You may choose from a variety of source control tools, such as git, SVN, or Mercurial, but this choice will impact the CI/CD tooling you may use later on.

After choosing a source control tool, you'll need to pick a hosting service compatible with that tool. Common choices include Github and Bitbucket. The service you choose will impact which tools you may use for other stages in the CI/CD pipeline, and you'll need to familiarize yourself with the hooks that the service uses to communicate with outside systems.

Choose a CI/CD tool

There are several factors at play when choosing a CI/CD tool for your organization. For example, some tools are proprietary, enterprise-grade tools that are designed to be more "plug-and-play" in your existing tech stack. There are also open-source, self-hosted solutions that require more extensive setup, however, they allow for more flexibility in your automation workflow. Some tools are self-hosted and others are offered as a software-as-a-service solution. There's also a mixture of all of the above attributes among the tools available.

Some common CI/CD tools include:

• Jenkins
• Travis CI
• CircleCI
• Drone

Regardless of your choice, you'll likely be scripting your CI/CD process—often called a pipeline —in a format your tool understands. These pipeline scripts often include the following:

• A software image—for example a Docker container —for the server to use when running its commands. This ensures the server has all the software needed to build your application, test it, package it, etc.
• Conditional when statements, i.e. the events that kick off the pipeline's commands. These are often set from events on your shared repository system. For example, a test pipeline may only test part of a project for test branches, while a production release pipeline may run a full automated testing suite when work is merged into a release branch.

You'll also need credentials for your staging and production platforms stored in your CI/CD tool of choice, as you'll be retrieving data from one to send to the other.

These configurations have little to do with Nintex itself., they just determine how the metadata that makes up Nintex sites will be stored, tested, and published. Thus, Nintex builders will need to work closely with their IT organization to determine a proper ALM approach.

Continuous Delivery

Automated Testing

To ensure that an update has not broken any functionality within an application, consider implementing an automated testing pipeline stage within your CI/CD stack. By making extensive use of the unique ID property within a page's Nintex Apps components, it is possible to script basic test cases that can then be run within the testing framework of your choice.

For more information, see our Automated Testing topic.

Packaging

Nintex Apps applications do not require a packaging stage in the CI/CD pipeline, as the Nintex Apps CLI handles the movement of all necessary metadata objects—though connection credentials must be manually re-entered in the target site.

In contrast, Salesforce applications—and thus applications built using Nintex Apps —do require packaging steps before deploying to a target Salesforce org. For more information, see the Create a Package topic from Salesforce DX documentation.

Continuous Deployment

Deployment ensures that—after completing the rest of the pipeline steps—your applications are published in a form your users can access. For Nintex Apps applications that means deploying your metadata objects or application package. Where and how that deployment is accomplished depends on your platform of choice.

Deploying Nintex Apps metadata objects involves the Nintex Apps CLI command. If all necessary credentials are stored in the CI/CD tool, and the Nintex Apps resources are stored within a git repository checked out by the CI/CD tool, then this pipeline stage may look like the following:

1
2
3
4
# Deploy that data to the production site with another set of credentials
echo "New commit merged to master. Deploying to $PRODUCTION_HOST..."
skuid deploy --username $PRODUCTION_UN --password $PRODUCTION_PW --host $PRODUCTION_HOST --dir skuid-data

Note:  Some configurations are not currently retrievable via the CLI. See the Manual Deployment Steps section of the Sandbox Deployments topic.