How You Can Benefit From Continuous Integration

When we started Damn Fine we were serious about creating an environment that would make us as efficient as possible. Our time is precious and we want to make sure we're spending it on what we do best; executing high-quality design and development for our clients. To that end we experiment a lot with new tools, tech and processes. One year in, some of these processes are now a core part of how we work and one of the greatest success stories so far has been the dual implementation of CircleCI and Capistrano for continuous integration.

Designing in the open

One of the fundamental values Damn Fine is built on is being open and transparent. One of the ways this manifests itself is in our communication during the design and build phase of a project. We never want to disappear for six weeks only to reappear on the other side with a 'finished' product.

The best products are the result of close collaboration between domain experts (that's you) and outstanding technical talent (that's us). Continuous integration is the continual testing and deployment of a project, it let's us focus on designing and building whilst giving our clients immediate access to the most recent build of their project. We're able to iterate and integrate feedback fast, without worrying we're about to break something, and knowing that the client will see those updates in real time.

So, why CircleCI?

Every now and then I discover an article on Hacker News that fundamentally changes the way I work. Reading up on CircleCI was undoubtedly one of these moments. I hadn’t experimented with a continuous integration service before, but the promise of it seemed to be everything I was looking for. Fast, reliable deployment without sacrificing stability. Where CircleCI really stands out though is how much it can infer from your project, giving you a wealth of information about how you should be testing your project. The user interface makes drilling into the details intriguing, rather than daunting. Suffice to say I was hooked. Before long I was approaching deployment with continuous integration first, rather than something I would be integrating CircleCI into later.

Now, before I write any code on a project, I set it up on CircleCI first so I have another set of eyes keeping an eye on stability whilst we concentrate on building.

What about deployment?

CircleCI takes care of the testing, but we still need to deploy our “passing” builds so that they can be viewed by the client. For this we chose Capistrano, a language agnostic deployment tool written in Ruby. Using a deployment tool like Capistrano gives us the added security of removing more potential human error from the process. It provides us with release versioning, so we are able to revert to a stable version if something goes wrong very quickly.

Our setup

We use a development methodology called Gitflow (first written about by Vincent Driessen on his blog) which allows us to develop new pieces of functionality in parallel with fixing bugs on the current production build.

We create three different environments whilst we work: - Alpha - Beta - Production

Alpha is for the most recent build of any type, whether it’s a new piece of functionality we’re working or a bug fix. It’s a place for us to check our work on a live environment.

Beta contains more stable builds and is exposed to the client, so they can see a version of the project before it’s released to the public. This is ideal for feedback and final checks.

Production is the live version of the project.

Once CircleCI has “passed” a new build it will trigger a Capistrano event. Capistrano figures out whether this is a new piece of functionality, a new bug fix, a beta release or a production release. It will then update the relevant environment for us. With CircleCI’s integration with Slack we are notified immediately on successful builds and we can notify the client immediately that there is something new to see.

The beauty of this approach is in the way it supports our process of designing in the browser, seeking feedback early, and iterating fast. No matter the size or stage of a project, we can open an effective dialogue with our clients based around what they actually see in the browser. Integrating feedback and prototyping new interactions doesn't also mean a big redeployment effort. And, most importantly, we get to spend less time fiddling with servers and more time building great products.