Tuesday, November 20, 2012

Continuous integration for a Rails-based project. Why we moved away from TravisCI in favour of CircleCI.

We've faced an issue recently with TravisCI on a Rails project, that would better be avoided next time.

Initially we've chosen TravisCI due to an easy/simple project start based on it. Although it didn't support private repos, the project was in a public repo, so that wasn't a problem. It was a real good CI solution actually.
But our app specifics made its unit tests to be rather time-consuming at that stage (http requests making and their responses usage in the tests), so TravisCI in its turn was just interrupting the tests after 25 minutes, leading to build failures of course. As it turned out, this 25 min limit was NOT configurable in Travis (it becomes important in some cases, so it's looking rather dully to have such a limitation, isn't it?), so we had to look around a bit.

CircleCI became a good replacement. Allowing the tests without that limitation - it became the solution at that stage. A very simple quick setup, a clean nice list of revisions with build statuses, and (compared to Travis) while in its beta, for now, allows private repositories for free.

By the way, later we've "eased" the tests when running on the side of CI, in the sense of time consumption - a VCR-based optimizing solution (records your test suite's HTTP interactions and replays them during future test runs for fast, deterministic, accurate tests) allowed to greatly speed them up there - by reusing the HTTP responses VCR cache generated locally and then pushed to Amazon S3 storage for sharing among the environments. So that "25min limit issue" has lost its actuality in our case. But still, CircleCI has "occupied" the status of problem solver since the previous case :)

P.S. Thanks to Paul Biggar @ CircleCI for being so attentive and quick with his help when needed.