Feature staging deployment for static pages

3 min readJun 24, 2016

Introduction

It’s nice to have your static pages being deployed and served separately from your application. This can give you benefits like smaller downtimes, shorter deploys, reduced load on you application servers and more. Of course there can also be downsides like more complicated setup.

For projects that are actively developed I prefer having staging environments per feature where the effect of changes made can be verified in isolation. Lately creating this kind of setup with tools like Heroku is getting close to effortless.

The problem

This is great for applications you deploy to Heroku, but what to do if you want to have the same setup for your static pages, blog or single page application that you deploy to github pages or a content delivery network…

Possible solutions

Test on Heroku

An option is to deploy a staging/test environment to Heroku and let Heroku create Review apps for each pull request submitted. This might not be optimal as there will be quite some differences between your staging and production environments.

Do it yourself

Another option is to recreate this setup by using a CI tool and your production infrastructure. In our case it would be Travis-CI (because Travis Rocks!) and Amazon S3/cloudfront. The good thing is that Travis-CI supports deployment out of the box and even deployment to S3. But every good thing has to be followed by something not that good in order not to ruin the overall experience. So from Travis-CI documentation:

Note that pull request builds skip deployment step altogether.

As the main purpose of this is to automatically deploy on pull requests, we can’t really use the integrated Travis-CI deployment and have to recreate that inside the regular build step. To get all the awesomeness from S3 deployment outside of Travis deployment step we can use the s3_website tool.

Quick example of Travis-CI & S3/Cloudfront

Let’s create two S3 buckets production and staging. All commits in master get deployed to the production bucket and every pull request gets deployed to a subfolder inside the staging bucket.

# s3_website.yml
s3_endpoint: eu-west-1
site: public
s3_id: <%= ENV['S3_ID'] %>
s3_secret: <%= ENV['S3_SECRET'] %># change bucket based on travis ENV
# chechk for PR required as branch in PR's always is master on travis
<% if ENV['TRAVIS_BRANCH'] == 'master' && ENV['TRAVIS_PULL_REQUEST'] == 'false' %>
s3_bucket: honeypot-staticpages
cloudfront_distribution_id: <%= ENV['DISTRIBUTION_ID'] %>
<% else %>
s3_bucket: staging-honeypot-staticpages
cloudfront_distribution_id: <%= ENV['STAGING_DISTRIBUTION_ID'] %>
s3_key_prefix: <%= ENV['PREFIX_FOLDER'] %>
<% end %>

As we only want to deploy on master and pull requests we need to block deployment for other builds. For that I’ll create a simple shell script bin/deploy

#!/bin/bash
if [ "$TRAVIS_BRANCH" == "master" -o "$TRAVIS_PULL_REQUEST" != "false" ]
then
  bundle exec s3_website push
else
  echo "no deployment for branch $TRAVIS_BRANCH"
fi

The last things still missing are setting the PREFIX_FOLDER env variable that is used as staging subfolder name and instructing Travis to run the freshly created bin/deploy script

language: ruby
script: ./bin/deploy
env:
  PREFIX_FOLDER: $([ "$TRAVIS_PULL_REQUEST" != "false" ] && echo "pr-$TRAVIS_PULL_REQUEST")

After pushing this and creating a pull request Travis CI will automatically deploy deploy your changes under:

http://<bucket-name>.s3-website-eu-west-1.amazonaws.com/pr-<your-PR-number>

TODO

[ ] Notify github about the creation of a feature staging
[ ] Delete subfolder when PR is closed
[ ] Move logic from yaml files to the deploy script

This blog post was originally published on Honeypot’s blog. Honeypot is a developer-focused job platform, working with great tech companies in Germany and Holland.