Build and Deployment System

A good book I read* stated that before you start to code, you should first build your build and deployment system.

This makes sense to me as one of the things I want to accomplish with Lecker is the ability to have Continuous Deployment, and the best way to do that is build the code around the deployment system, not the other way around.

Obviously I have already started on the code, but we're not too far in to change tack and now focus on the build and deployment system.

A good place to start with the deployment system is Ben Gourley's blog post on Deploying Node.js Apps.

Objectives of the Build/Deploy System

The objectives really are very simple:

• Pushing to the Live Server git remote triggers the build
• The build should either backup the current build, or operate some sort of versioning as in Ben's post
• The build should install all dependencies
• The build should run all tests, exiting on failure
• The build should stop the current running instance of the build and start the new instance
• On any failure the build should stop and I should be notified
• On success I should be notified

Unit and Behaviour Tests

Obviously, before we deploy a new version we should run all tests to ensure it works. However, where to run the tests? Should we run them on the actual live server as part of the deployment, or should we run them before we even deploy to the server?

Testing on the live server will always be better from the point of view that the development and live servers may differ - different versions of Node, different versions of modules etc. A test that passes on one setup may very rarely not pass in another setup.

However, then, do we test with live data? I'd rather not. But if we don't, should we keep two versions of the database ("real data" and "test data") running on the live system? This is relatively trivial when using MongoDB as Lecker is. But if we then want to take what we learn from here and apply it to a site running of say MySQL, then what if the scheme changes? We have to ensure both the real and test databases are up-to-date. This could induce headaches!

Continuous Integration

As well as Continuous Deployment we should also use Continuous Integration. Both Jenkins and Bamboo are decent systems for this (the former being open source). From our point of view, at ibrow we use Bamboo as at the time setup was far easier.

The CI build needs to differ slightly from the CD build:

• Code coverage reports should be generated
• No need to create versioned directories, or backups
• No need to stop and start the site.

There is no reason the same build script can't be used for both, but based on params the different builds initiated.

Tools

Seeming that we are building a Node.JS project, it would be silly not to use Jake for the build.

* I can't remember which book it was, but I'm going to have a dig about because it really was a good read