Setting up continuous deployment allows you to automatically upload your changes to your desired environment.
Before setting up continuous deployment:
- 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.
- 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 provision a deployer account with permission to deploy to a single space, set up an instance of a cloud.gov service account.
Continuous integration services
To set up any of these services, you will need to provide a
manifest.yml file that captures the intended deployment configuration for your application.
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 master branches, along with using a staging or QA deployment with the development branch, and a production deployment with the master 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: master
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
language: ruby rvm: - 2.1 script: jekyll build ./_site deploy: skip_cleanup: true # ...
For details, see Jekyll’s Continuous Integration guide.
Add these items to your
dependencies: pre: - curl -v -L -o cf-cli_amd64.deb 'https://cli.run.pivotal.io/stable?release=debian64&source=github' - sudo dpkg -i cf-cli_amd64.deb - cf -v test: post: - cf login -a https://api.fr.cloud.gov -u DEPLOYER_USER -p $CF_PASS -o ORG -s SPACE deployment: production: branch: master commands: - cf push
SPACE accordingly, and export the
CF_PASS environment variable in the Circle interface to add the deployer’s password.
Note: If your
manifest.yml describes more than one app, you might want to specify which app to push in the
cf push line.
wercker.yml file, add:
steps: ... - dlapiduz/cloud-foundry-deploy ... deploy: steps: - dlapiduz/cloud-foundry-deploy: api: $CF_API username: $CF_USER password: $CF_PASS organization: $CF_ORG space: $CF_SPACE appname: APP domain: DOMAIN hostname: myapp skip_ssl: true
DOMAIN to match your application, and set up the following environment variables in a “deploy target”:
You can also add the
alt_appname attribute to do Blue-Green deploys.