Continuous Integration, and Automated Deployments

A relevant ad will be displayed here soon. These ads help pay for my hosting.
Please consider disabling your ad blocker on Pony Foo. These ads help pay for my hosting.
You can support Pony Foo directly through Patreon or via PayPal.

In the next post I’ll get back to the meat of how I’m making progress with the blog application. This time however, I wanted to deviate a little, and talk about Continuous Integration, and automated build processes, the like of which you can achieve with PaaS services (also known as Platform as a Service), such as AppHarbor, Heroku, and many others.

Continuous Integration

Configuring Travis CI was tricky to get right. I configured my .travis.yml file like this:

language: node_js

  - 0.8

  - "npm install"
  - "cd src"
  - "make test"

This simple configuration just makes sure the server runs on Node.JS 0.8.x, and then it runs a little script, where all npm packages are installed, and then it runs any unit tests I might have written, making use of a Makefile.

I didn’t actually write any tests just yet, but I will once I get more comfortable with Node.JS, and until then, this will come in handy anyways when I forget to include a package in my JSON config.

Automated Deployments

Heroku is an scalable web platform. You can get set up in a few seconds, and all you really need to do to configure your application is create what they call a Procfile, mine is simply:

web: node src/server.js

This configures my Heroku application to host a web process and employ src/server.js as the Node.JS web server. I followed this guide to great success. And now, whenever I want to deploy, I can just issue the following git command:

$ git push heroku master

That’s it. I might even configure a staging environment, which would be an exact replica of my production environment (hey, it’s free!), except it would have dummy data, and it would be useful to prevent deploying faulty builds directly into production.

To manage multiple environments, environment configuration variables come in handy, to store secret values such as your session secret, your database connection string, and particularly, the environment name (such as development, staging, or production).

Having a one-step build process is crucial to minimizing room for mistakes during manual deploys, and mandatory if you are serious about protecting your production environment from development bugs. Manual deploys can lead to mistakes like forgetting to copy a file, or replace a configuration value, or many other mistakes, reasons why you should be doing automated builds if you aren’t already.

Liked the article? Subscribe below to get an email when new articles come out! Also, follow @ponyfoo on Twitter and @ponyfoo on Facebook.
One-click unsubscribe, anytime. Learn more.