Deploying Federalist from TravisCI
This guide covers how the deployment process for Federalist and Federalist Builder works. In order to understand the process for Federalist Docker Build and Federalist Registry, see the cloud.gov setup guide.
Federalist is deployed by TravisCI. Federalist and Federalist Builder are configured such that changes to the master branch are deployed to production and changes to the staging branch are deployed to staging. In both repos this configuration lives in the .travis.yml file in the project root.
Both projects use a file at
scripts/deploy-travis.sh to run the actual deploy.
These scripts authenticate with cloud.gov using a cloud.gov deploy user.
Despite some minor differences, both of these scripts do essentially the same thing:
- Check the current branch and use it to determine which space to deploy to
- Install Autopilot for cf-cli (used for zero downtime deploys)
cf loginto authenticate the deploy user
- Do a zero downtime push of the application
It is worth noting that the environment for these scripts is set in the
.travis.yml for the following:
CF_API: The Cloud Foundry API endpoint, for example
CF_USERNAME: The username for the cloud.gov deploy user
CF_ORGANIZATION: The Cloud Foundry org where the app is deployed
CF_PASSWORD: An environment variable for the cloud.gov deploy user's password
Zero downtime deploys
Federalist has high availability requirements because it needs to be up to receive GitHub webhook and build status requests. Because of this, the autopilot Cloud Foundry CLI plugin is used so the app can be deployed without downtime.
Zero downtime deploys work by:
- Renaming the app to
<appname>-venerable, for example
- Pushing a new app with the old app's name
- When the new app is started, routing requests to the new app and deleting the venerable app
Cleanup after a failed deploy
If autopilot fails to deploy the new app, it exits and does not clean up after itself.
So after a failed deploy there will be a stopped app named
<appname> and a running app named
<appname>-venerable fielding requests.
This is by design so that a failed deploy does not cause the app to go down.
The downside of this setup is that all future deploys will fail since there will be a name collision on
As a result, the failed deploy will need to be cleaned up before another deploy can succeed.
To cleanup after a failed deploy:
- Delete the new app. For the main Federalist app that would be
- Rename the venerable app to the name of the new app. For example, rename
- Start a build on Travis to re-deploy.