Regular automated builds and testing of a code base. We are using CircleCI to facilitate CI (and sometimes CD, see Container Runtime).
GitHub -> CircleCI -> CodeClimate
\> CodeClimate
Setup documentation
Example configuration
CircleCI v2.0 runs inside of Docker image/container of your choosing. We have authored an image (technekes/circleci:latest) that includes Docker Compose allowing for us to run specs in a manner very similar to our development environment.
- docker-compose
- Danger
- nib-crypt (future)
Test coverage can be captured by simplecov while running specs and reported to CodeClimate for integrations with a repos analysis. Additionally the simplecov output can be stored as a build artifact CircleCI (example).
Delivering every successful build to staging to allow for acceptance testing. This is not Continuous Deployment which would be delivering each successful build into production.
GitHub -> CircleCI -> Heroku (staging)
A Heroku app can be configured to deploy automatically when code is pushed to a specified branch and CI passes.
Heroku apps can be configured for zero downtime deployments by enabling preboot. Preboot will deploy new code to a new Dyno, ensure the application boots successfully, and wait for 3 minutes before pointing the load balancer at the new dyno(s).
Apps on Heroku can deliver deployment notifications to a URL. We use this feature along with Rollbar to track deployments and trigger notifications from Rollbar into Slack.
Heroku application and addon logs can be accessed via the Heroku CLI.
# follow the logs of Fluxer staging
heroku logs -t -a tk-stage-fluxer
# or from a directory named `tk-fluxer`
nib logs -f -e stage
# or if the app uses papertrail
heroku addons:open papertrail -a abc-stage-web-app
The traditional git push
deployment on Heroku takes advantage of the Common Runtime. Recently Heroku has added support for running arbitrary Docker container via the Container Runtime (docker push
).