ponyfoo.com

Continuous Integration, and Automated Deployments

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.

Improve this article
Nicolás Bevacqua
| 2 minute read | 1

Continuous Integration

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

language: node_js

node_js:
  - 0.8

script:
  - "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.

Comments (1)

Eric Douglas wrote

Great tips!