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.
Comments