Looking for our Bitbucket add-on?Click here to read about recent Aerobatic changes.

Continuous Deployment

Deploying your website directly from your local terminal is a great way to get started with minimal friction. However as the deployment process matures and particularly if there’s a team of contributors, it makes sense to move to a CD workflow where git commits automatically trigger a build and deployment of the website using a CI/CD service.

The aerobatic-cli can easily be installed and run as part of a build script with any of the growing set of CI/CD tools and services such as: Jenkins, Travis, Bitbucket Pipelines, Wercker, Codeship, CircleCI, AWS CodeBuild, and more.

All the examples below are based on a Jekyll site being built by Travis, but the basic concepts are all transferrable to other static site generators and CI/CD services.

Travis uses a .travis.yml file to specify the build and deploy steps. Here’s where we specify how to run the jekyll build step. After the build step has completed successfully, aerobatic-cli is globally installed from npm. Finally the aero deploy command will deploy the built assets as a new version to Aerobatic. In this case we are deploying to the production stage. Further down in this article we’ll talk about how to deploy to test, staging etc.

language: ruby
    - secure: <encrypted_env_vars> # See AEROBATIC_API_KEY below
  - rm -rf ~/.nvm && git clone https://github.com/creationix/nvm.git ~/.nvm
  - (cd ~/.nvm && git checkout `git describe --abbrev=0 --tags`)
  - source ~/.nvm/nvm.sh
  - nvm install $TRAVIS_NODE_VERSION
  - bundle install --path vendor/bundle
  - npm install
  - bundle exec jekyll build
  - npm install aerobatic-cli -g
  - aero deploy \
    --commit-url "https://github.com/owner/repo-name/commit/${TRAVIS_COMMIT}" \
    --directory _site

You’ll notice in the aero deploy call above we are passing two arguments: --commit-url and --directory. The commit-url is simply the URL to the commit that triggered the build. This is optional, but if provided the Aerobatic control panel will include a link back to this URL in the deployment history which can be helpful for maintaining a connection between the code changes and what was deployed. The directory argument is the directory where the built assets were written which, in the case of jekyll, defaults to _site. This can be specified as a CLI arg or it can be declared in the deploy section of aerobatic.yml.

API Key environment variable

An environment variable named AEROBATIC_API_KEY needs to be set in the build script in order to make authenticated calls to the Aerobatic API. Each CD service has a mechanism for setting environment variables. It’s recommended that the value be encrypted if your service supports it. Travis provides a command line tool for encrypting a variable and injecting it into the .travis.yml file:

$ travis encrypt AEROBATIC_API_KEY=<your_api_key> --add env.global

You can get the value of your enviroment variable by running the apikey command. All websites associated with an Aerobatic account will have the same API key value.

$ aero apikey

Deploy stages

The example above will deploy any branch configured for CI to the production branch. However you may want to deploy different branches to different instances of your website. This is straightforward using Aerobatic deploy stages - albeit with a little bash trickery. We are now passing an additional stage argument which specifies the name of the stage to deploy to. If the stage name is anything other than “production”, the stage is incorporated into the deployed URL, i.e. https://www--test.domain.com or https://test.domain.com (if the production URL is using an apex domain). This script is using the convention that the master branch is deployed to production and anything else is deployed to a stage named the same as the branch.

  - npm install aerobatic-cli -g
  - aero deploy \
    --commit-url "https://github.com/owner/repo-name/commit/${TRAVIS_COMMIT}" \
    --stage $([ $TRAVIS_BRANCH = 'master' ] && echo 'production' || echo $TRAVIS_BRANCH ) \
    --directory _site

This setup is a bit cleaner with some of the other CI services. For example Bitbucket Pipelines and Circle CI (and probably others) provide the flexibility to define distinct deploy steps per branch.