Skip to main content
undefined
undefined

Official websites use .gov
A .gov website belongs to an official government organization in the United States.

undefined

Secure .gov websites use HTTPS
A lock ( ) or https:// means you’ve safely connected to the .gov website. Share sensitive information only on official, secure websites.

Continuous deployment

Table of Contents

Setting up continuous deployment allows you to automatically upload your
changes to your desired environment.

Get ready

Before setting up continuous deployment:

  1. Go through the production-ready guide to ensure your application uses the core best practices and zero-downtime deployment. This will help you use continuous deployment with reduced risk of errors and outages.
  • The essential requirements: your code needs to be in version control, and it needs to include a manifest.yml  file that captures the intended deployment configuration for your application.
  1. Set up continuous integration. This will protect you from deploying a broken application. You can use the same service for continuous integration and continuous deployment — see the list of continuous integration services below for suggestions.

Provision deployment credentials

Continuous deployment systems require credentials for use in pushing new versions of your application code to cloud.gov. You should use a restricted set of credentials that can only access a particular target space, rather than credentials tied to a user who has more access, or who may lose access when leaving your team or project. This “least privilege” approach minimizes the harm that is possible if the credentials are compromised in any way.

To create deployer account credentials with permission to deploy to a single space, set up a service account.

Configure your service

cloud.gov does not provide a CI/CD (continuous integration/continuous deployment) service, but you can use any CI/CD service of your choice.

You can configure your code repositories, spaces, and CI/CD service together to enable automated or semi-automated deployments to your environments (such as development, staging, and production environments). For deployments in each environment, you can configure access control and testing requirements according to your project’s needs.

The core concept is to set up a script that triggers when you update the material that you want to test and deploy (typically your code in your version control system). The script runs your commands, including your deploy command, using your service account credentials.

To illustrate how a CI/CD workflow could be incorporated with cloud.gov:

graph TD

subgraph cloud.gov
  subgraph Org
  subgraph Dev space
      Dev[App]
    end
    subgraph Staging space
      Staging[App]
    end
    subgraph Production space
      Prod[App]
    end
  end
end

Developer((Developer)) -->|Commit code| Repo(Code repository)
Repo -->|Automatically notify that a commit happened|CD(Continuous Deployment service)
CD -->|If dev branch, deploy| Dev
CD -->|If staging branch, deploy| Staging
CD -->|If prod branch, deploy| Prod

Another example of a CI/CD workflow (this illustration omits the org/space boundaries):

graph TD

Developer((Developer)) -->|Commit code| Repo(Code repository)
Repo -->|Automatically notify that a commit happened|CD(Continuous Deployment service)
CD -->|If dev branch, deploy| Dev(Dev app on cloud.gov)
CD -->|If prod branch, deploy, run tests | Preprod(Preprod app on cloud.gov)
Preprod --> | Test results | CD
CD -->|If preprod tests OK, deploy prod branch| Prod(Prod app on cloud.gov)

Service examples

Here are examples of how to set up three cloud-based services that have free tiers for open source projects, Travis, CircleCI and GitHub. (You can also find and adapt instructions for using other CI/CD services with other Cloud Foundry deployments, such as this explanation of how to use Jenkins.)

Travis

See the Travis documentation.

Use api: https://api.fr.cloud.gov 

You must encrypt the password, and you must escape any symbol characters in the password, to prevent possible situations where Travis could dump an error message that contains passwords or environment variables.

For more information about configuring Travis, see Customizing the Build.

Using Conditional Deployments with Travis

A common pattern for team workflows is to use separate development and main branches, along with using a staging or QA deployment with the development branch, and a production deployment with the main branch. This can be achieved in Travis with on:  to specify a branch, and using unique manifests for each deployment.

deploy:
  - manifest: manifest-staging.yml
    # ...
    on:
      branch: develop
  - manifest: manifest.yml
    # ...
    on:
      branch: main

Each manifest should at the very least define an unique name , but can also define an unique host . Also, it may be necessary to define unique services for each application to use. See Cloning Applications for more information.

Jekyll with Travis

To deploy a Jekyll site, add the following to your .travis.yml :

language: ruby
rvm:
  - 2.1
script: jekyll build ./_site
deploy:
  skip_cleanup: true
  # ...

For details, see Jekyll’s Continuous Integration guide.

CircleCI

See Getting Started with CircleCI – you’ll need to set up a CircleCI account and give it access to your code repository.

In your code repository, use the following template to set up your circle.yml  file. This uses CircleCI 1.0 syntax.

dependencies:
  pre:
    - curl -v -L -o cf-cli_amd64.deb 'https://packages.cloudfoundry.org/stable?release=debian64&version=v8&source=github'
    - sudo dpkg -i cf-cli_amd64.deb
    - cf -v

test:
  post:
    - cf login -a https://api.fr.cloud.gov -u DEPLOYER_SERVICE_ACCOUNT_USERNAME -p $CF_PASS -o ORG -s SPACE

deployment:
  production:
    branch: main
    commands:
      - cf push

Replace DEPLOYER_SERVICE_ACCOUNT_USERNAME , ORG , and SPACE  with your information. Do not replace $CF_PASS  with your deployer service account password – instead, export the CF_PASS  environment variable in the CircleCI interface and put the deployer password there.

You can also review their sample circle.yml file for more configuration options.

Note: If your manifest.yml  describes more than one app, you might want to specify which app to push in the cf push  line.

GitHub Actions

See the GitHub Actions documentation to get started, and this pre-made GitHub Action.

Usage

After following the instructions for setting up a cloud.gov service account, store your username (CG_USERNAME) and password (CG_PASSWORD) as encrypted secrets.

Sample workflow

The following is an example of a workflow that uses this action. This example shows how to deploy a simple .NET Core app to cloud.gov

name: .NET Core Deploy

on:
  pull_request:
    branches: [main]

jobs:
  build:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v2
      - name: Setup .NET Core
        uses: actions/setup-dotnet@v1
        with:
          dotnet-version: 3.1.101

      - name: Install dependencies
        run: dotnet restore

      - name: Build
        run: dotnet build

  deploy:
    runs-on: ubuntu-latest
    needs: build

    steps:
      - uses: actions/checkout@v2
      - name: Deploy to cloud.gov
        uses: cloud-gov/cg-cli-tools@main
        with:
          cf_api: https://api.fr.cloud.gov
          cf_username: $
          cf_password: $
          cf_org: your-org
          cf_space: your-space

Note the reference to cloud-gov/cg-cli-tools@main  in the workflow file above. You can use another workflow file as part of your deployment process if you desire, or add additional steps to your workflow by referencing other GitHub actions.