The first two parts of the blog series covered what tools Appian provides to build CI / CD and the considerations that need to be made before starting an implementation and how to setup cucumber for Appian and run your tests locally. The final part of this CI / CD with Appian series will cover how to automate the tests created in the last blog using Jenkins, as well as some final considerations.

We will be building a Jenkins pipeline that runs a simple Cucumber test against an Appian Application in a managed cloud environment. Jenkins will run the test, and if it passes, send a notification out via Slack.

Before starting, make sure you have an active Appian instance, a git repository in a platform like Github or Bitbucket, and admin access to Jenkins running on an Ubuntu system or a docker container with Chrome installed (hint - these images may help). This tutorial can be done on windows or mac with a similar procedure, but the specifics will not be covered in this post.

Note: The end result of this project is only a starting point. Implementing a fully automated production grade CI/CD pipeline for an Appian Application is not an easy task since it requires significant customization, so the tutorial is geared towards developers with advanced knowledge. Technical and personnel challenges like security, hardware utilization, and concurrency must all be considered before implementing this solution in a production scenario.

Before deciding to implement CI / CD for your organization, decision makers may want to consider the following:

  • What are the current capabilities of the development team?
    • Do they know how to build new solutions on the Jenkins platform?
    • Is the necessary server infrastructure in place to run a Jenkins machine and it’s build agents?
    • Is someone ready and available to implement a solution like this?
  • Is a testing strategy in place?
    • How frequently are tests going to run?
      • Have the advantages + disadvantages of not testing immediately been considered if it’s not possible to do so?
    • What environment will the tests run in?
    • How will you know testing procedures are handled for every feature being developed?

Appian Setup

First, we need to create an application to test. If you don’t have an application already, you can import the Appian Application linked here into your Appian Environment. If you aren’t familiar with how to import applications, follow the steps linked here.

Important: In order to make sure your Appian environment stays secure, and to test the application effectively, make sure you create a basic user and add that user to the “ACD All Users” group. Take care to not run tests with an admin user or ever commit a password into version control.

Cucumber Setup

To make things easy, download (or clone) this repository at the linked commit and move the contents over to your local project repository. Once you have downloaded the repository, configure your repository to test against your Appian environment by making a few small changes 

  • Line 7 in the `ApplicationExample.feature` - add in your Appian URL
  • Line 1 in the `` file - the basic user’s username and password that we created in the last section

Run mvn clean test to ensure that your tests work on your computer. If the tests fail here, they will not work on Jenkins. If you’re having trouble, ensure the application is imported into your Appian environment successfully.

Jenkins Environment Setup

Before we create anything related to Appian in Jenkins, we need to make sure our Jenkins machine is configured to run tests. We’ll start by adding a few plugins to Jenkins. Click on Manage Jenkins > Manage Plugins. Click the Available tab, and search and install (without restart) the following plugins

See the documentation here if you need further help with adding plugins to Jenkins

Since the Jenkins server runs on a different computer than our development machine (or in a docker container), we need to add a for the jenkins machine. Additionally, we need to add a file so we don’t have to check in passwords. Do this by going to Manage Jenkins > Managed Files > Add a New Config. Set the file type to “Properties File”, and set the ID’s to “” and “”. Once in the editor, paste in the contents of the file from your computer, and paste the contents of this file into the file

JenkinsFile Creation

A JenkinsFile is a groovy based file that gives Jenkins a set of commands to run a job. In the main folder of your cucumber application, create a file named JenkinsFile, and copy the contents from this file over. The explanations of what everything does is below.

First we’re defining the job as a scripted pipeline and tell IntelliJ to treat the file like a groovy file. While scripted pipelines are older than declarative pipelines, they offer more flexibility when working with solutions like Appian.  


node {

Next, we will define the stages of the pipeline. The process will go like this:

  • Check out the code from source control
  • Copy over the property files for running the tests
  • Run the tests
  • Notify the team about the test results

This block of code will check out the code you commit to source control and copy the property files we just added to the build’s workspace.

stage('Prepare Test Environment') {
checkout scm

configFileProvider([configFile(fileId: '', targetLocation: 'src/main/resources/configs/')]) {
configFileProvider([configFile(fileId: '', targetLocation: 'src/main/resources/configs/')]) {
sh "sh"

Now we will run the tests. We’ll use the maven plugin to actually execute the tests from the command line. We need this plugin so we can have a sandbox environment that will not affect the rest of the Jenkins machine if something were to go wrong.

stage('Unit Tests - Cucumber') {
withMaven(maven: 'Maven 3') {
sh "mvn clean test"

Now we will notify a slack channel that the tests have completed. And the team can review the test results by clicking on the link.

stage('Notify Team of Test Passing') {

def attachments = [
color: '#36E72E',
text : "Testing build #${BUILD_NUMBER} completed \nLink: ${BUILD_URL}"

slackSend (
channel: "appian-internal-ci",
attachments: attachments

Your Slack notification will look something like this once we are done: 

slack notification

Jenkins Job Setup

Now that we have our JenkinsFile set up in the testing application and our Jenkins machine has been prepared, we need to add the job into Jenkins. Let’s start by creating a new one in Jenkins by clicking “New Item” on the top left corner of the screen. 

job setup

Once in the wizard, select “Multibranch Pipeline”.

Scroll down to the “Branch Sources” section and select your git provider. When prompted for credentials, click the add button and enter in your login details for the git account. Important: make sure the repository owner’s username is put in the owner field.

Once the connection is established to your git provider, select the repository that will host the Appian code. If you don’t have a repository yet, follow these instructions from Atlassian to create the repository.

setup fields

Click “Save”, and you will see a page that says “Scan Multibranch Pipeline Log”. If you don’t see that, click on “Scan MultiBranch Pipeline Now” on the left-hand side of the page. 

left menu

The build should start automatically and once it completes your Stage view will contain a success message

stage view


Congratulations! You should now have a working pipeline for testing Appian Cloud Applications.

Remember that this is only a starting point, and getting a fully automated deployment and testing solution for Appian Applications will need a bit more customization to be completely production-ready. Project managers and developers alike need to fully consider all variables in play before making a decision to develop a solution like this.

For simplicity, the final product of this tutorial will only test against an actively developed cloud environment, and will not perform deployments upon test completion. When our team builds out Appian pipelines, we run tests against a local docker container and deploy new Appian code using the Automated Deployment Manager tool and associate processes, but this will not be covered. There is never a one size fits all approach for CI/CD, so this is only a starting point.