Continuous Integration – Tddium

The CoachUp engineering department is constantly refining its development process for the sake of efficiency. I wanted to spend some time talking about one change we’ve recently made that I really feel has maximized our development speed: setting up Tddium’s continuous integration environment (
I should begin by talking a bit about our development process at CoachUp. First, we attempt to get new features into production as quickly as possible. We push new releases of our code into production every single day. To ensure that we do not break existing functionality, we put a heavy emphasis on testing. More specifically, we put a heavy emphasis on automated testing. We’re a Ruby on Rails shop, so we leverage the great built-in testing functionality that comes with Rails (primarily rspec, but a variety of other utilities as well). Although none of our engineers subscribe to TDD fully, we are meticulous in ensuring that every piece of functionality that enters our codebase is accompanied by a corresponding set of tests. We have operated in this way since the company was started.

As a result of our practices, the test suite has grown larger each day, which has been both a blessing and a curse at the same time. The engineering team has a policy of not pushing any release to production if our test suite is not completely green. We realized that it was great that we were maintaining adequate test coverage across our application. But with a large test suite, the problems we ran into were twofold:

1. The amount of time in which our test suite ran constantly increased
2. As it took longer and longer to run our test suite, the frequency of test suite runs began to decrease (after all, we were running everything manually)

Our solution: Tddium continuous integration environment.

For those of you unfamiliar with Tddium and continuous integration, I’ll explain a bit about how we’ve integrated Tddium into our dev process to make us faster and more efficient. At CoachUp, we used Tddium to address the two problems mentioned above. We signed up for a Tddium account, which involved hooking up our github account and selecting a plan in accordance with the size of our test suite. After we were set up, the rest was really effortless!

From our perspective, we basically just develop as normal: create a new feature branch from our github repository, develop, push to github, issue a pull request, and merge when ready. In the background, Tddium works on our behalf to do several things. It will monitor our github repository and when a new feature branch is pushed up to github, Tddium springs into action by grabbing the new feature branch and cranking through our test suite. We then conveniently get an email report sent to us detailing the results of the test run. If the new feature branch introduces a regression bug, we know about it immediately and can fix it well before it even has a chance to become a problem. Further, Tddium makes it super easy to switch plans and add/remove workers based on your scaling needs.

For us, the move to Tddium greatly cut down on development time by letting us really step on the gas and develop at a face pace, knowing all the while that we would be notified immediately if we introduced any regressions into the codebase.

We’re constantly trying new tools and processes here at CoachUp to make us more efficient, and Tddium has been one of our biggest successes.

Bottom line: if you’re looking for a quick, easy, non-intrusive way to speed up your test suite and make your dev team more efficient, definitely check Tddium out!

This is what has worked for us. What tools have others used to boost the efficiency/productivity of their team?