AWS OpsWorks Deployment

This page documents deployments using dpl v1 which is currently the legacy version. The dpl v2 is released, and we recommend useig it. Please see our blog post for details. dpl v2 documentation can be found here.

Travis CI can automatically deploy your AWS OpsWorks application after a successful build.

For a minimal configuration, all you need to do is add the following to your .travis.yml:

deploy:
  provider: opsworks
  access-key-id: ACCESS-KEY-ID
  secret-access-key: SECRET-ACCESS-KEY
  app-id: APP-ID
  region: REGION # (default: us-east-1)

region isn’t required but it defaults to us-east-1. If your application is located in a different region you will get an error like “OpsWorks service error: Unable to find app with ID xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx”.

You can obtain your AWS Access Key Id and your AWS Secret Access Key from here. It is recommended to encrypt your AWS Secret Access Key. Assuming you have the travis client installed, you can do it like this:

travis encrypt SECRET-ACCESS-KEY --add deploy.secret-access-key

You can also have the travis tool set up everything for you:

travis setup opsworks

Keep in mind that the above command has to run in your project directory, so it can modify the .travis.yml for you. Note that the region isn’t generated by running travis setup opsworks.

Migrate the Database #

If you want to migrate your rails database on travis to AWS OpsWorks, add the migrate option to your .travis.yml.

deploy:
  provider: opsworks
  access-key-id: ACCESS-KEY-ID
  secret-access-key: SECRET-ACCESS-KEY
  app-id: APP-ID
  migrate: true

Deployment Branch #

By default, Travis CI will only deploy from your master branch.

You can explicitly specify the branch to deploy from with the on option:

deploy:
  provider: opsworks
  access-key-id: ACCESS-KEY-ID
  secret-access-key: SECRET-ACCESS-KEY
  app-id: APP-ID
  on: production

Alternatively, you can also configure it to deploy from all branches:

deploy:
  provider: opsworks
  access-key-id: ACCESS-KEY-ID
  secret-access-key: SECRET-ACCESS-KEY
  app-id: APP-ID
  on:
    all_branches: true

Builds triggered from Pull Requests will never trigger a deploy.

Deploy build artifacts #

After your tests run and before the deploy stage, Travis CI will clean up any additional files and changes you made.

Maybe that is not what you want, as you might generate some artifacts (think asset compilation) that are supposed to be deployed, too. There is now an option to skip the clean up:

deploy:
  provider: opsworks
  access-key-id: ACCESS-KEY-ID
  secret-access-key: SECRET-ACCESS-KEY
  app-id: APP-ID
  skip_cleanup: true

Waiting for Deployments #

By default, the build will continue immediately after triggering an OpsWorks deploy. To wait for the deploy to complete, use the wait-until-deployed option:

deploy:
  provider: opsworks
  access-key-id: ACCESS-KEY-ID
  secret-access-key: SECRET-ACCESS-KEY
  app-id: APP-ID
  wait-until-deployed: true

Travis CI will wait up to 10 minutes for the deploy to complete, and log whether it succeeded.

Update App Settings #

By default, the deployment from Travis CI triggers a deployment on OpsWorks but does not touch any other configuration. To also update the revision in App Settings use the update-app-on-success option. In addition, you have to set the wait-until-deployed option:

deploy:
  provider: opsworks
  access-key-id: ACCESS-KEY-ID
  secret-access-key: SECRET-ACCESS-KEY
  app-id: APP-ID
  wait-until-deployed: true
  update-app-on-success: true

Travis CI will wait until the deployment returns successful and only then update the revision in App Settings.

Conditional releases #

You can deploy only when certain conditions are met. See Conditional Releases with on:.

Run Commands Before or After Deploy #

Sometimes, you want to run commands before or after deploying. You can use the before_deploy and after_deploy stages for this. These will only be triggered if Travis CI is actually deploying.

before_deploy: "echo 'ready?'"
deploy:
  ..
after_deploy:
  - ./after_deploy_1.sh
  - ./after_deploy_2.sh