Skip to content

Run Tests Then Deploy


In this section we combine four ideas into a more advanced job:

  1. trigger the job anytime the application repo is changed
  2. run the internal unit tests of the application
  3. if successful, deploy the web application immediately
  4. use secret parameters for the target deployment platform

The resulting pipeline is a combination of the preceding lessons:

In the lesson we will deploy a sample Golang application to a Cloud Foundry platform. In your own Concourse pipelines you could deploy any application to any target platform.

For convenience, we're reusing the tutorials/basic/job-inputs/ test script from lesson Job Inputs.

- name: deploy-app
  public: true
  serial: true
  - get: tutorial
  - get: app
    trigger: true
  - task: web-app-tests
      platform: linux

        type: docker-image
        source: {repository: golang, tag: 1.9-alpine}

      - name: tutorial
      - name: app
        path: gopath/src/

        path: tutorial/tutorials/basic/job-inputs/
  - put: deploy-web-app
      manifest: resource-app/manifest.yml
      path: app

To deploy the run-tests-before-deploy pipeline, and trigger/watch the job:

cd tutorials/miscellaneous/run-tests-before-deploy
fly -t bucc set-pipeline -p run-tests-before-deploy -c pipeline.yml
fly -t bucc unpause-pipeline -p run-tests-before-deploy
fly -t bucc trigger-job -j run-tests-before-deploy/deploy-app -w

This will fail due to missing parameters.

Free Cloud Foundry for Lesson

To complete this lesson you will need access to a Cloud Foundry.

After signup, login to your account and navigate to your "org", create a new "space" called run-tests-before-deploy. This lesson's pipeline will deploy a sample app into this space.

The sample application being deployed by the pipeline is

Required Parameters


The example pipeline.yml in the lesson folder uses the cf resource for deploying the application via put: deploy-web-app. You could use any resource (or a handcrafted task) to deploy your application instead. Declarative deployment platforms like Cloud Foundry and Kubernetes can trivialise our pipeline implementation. They are the "Just Do It" of CI/CD deployment orchestration.

The cf resource deploys an application to Cloud Foundry. From the pipeline.yml it is:

- name: deploy-web-app
  type: cf
    api: ((cf-api))
    username: ((cf-username))
    password: ((cf-password))
    organization: ((cf-organization))
    space: ((cf-space))
    skip-cert-check: true

As introduced in Parameters and Secrets with Credentials Manager , the ((cf-api)) syntax is for late-binding variable, secret, or credential. This allows pipeline.yml to be generically useful and published in public. It also allows an operator to update variables in a central place and then all jobs will dynamically use the new variable values on demand.

It is likely that cf-api, cf-username, cf-password, and cf-organization are common credentials for many pipelines, but cf-space might be specific to this pipeline. Example credhub set commands might be:

credhub set -n /concourse/main/cf-api          -t value -v
credhub set -n /concourse/main/cf-username     -t value -v drnic+ci@starkandwayne
credhub set -n /concourse/main/cf-password     -t value -v secret-password
credhub set -n /concourse/main/cf-organization -t value -v starkandwayne

credhub set -n /concourse/main/run-tests-before-deploy/cf-space -t value -v run-tests-before-deploy

Once you've set your parameters in your Concourse credentials manager, or re-run fly set-pipeline to pass them in as variables, you can re-trigger the job:

fly -t bucc trigger-job -j run-tests-before-deploy/deploy-app -w


You can now delete the sample app from your Cloud Foundry account.