par8o speeds up Rails CI builds 8x with Semaphore Boosters

Before Semaphore:
  • Tests started taking 2 or more hours
  • Setting up parallel testing manually was tedious and time consuming
After adopting Semaphore:
  • 8x faster CI with Semaphore Boosters
  • Fully automated parallel CI

Par8o is a platform designed for healthcare teams to coordinate, communicate, and close the loop on patient referrals — for better relationships with providers and patients. par8o also offers a chat platform to encourage office-to-office and referral communication for quicker results.

Industry: Healthcare
Stack: Ruby on Rails, Angular, MiniTest, RSpec

The Challenge

At one point, running the tests on development laptops started taking the par8o developers 2 or more hours. As more tests were added, the time increased even further. Par8o started using Semaphore’s parallel job feature to distribute tests across multiple test builders. The goal was to have test feedback for a branch in less than an hour. Using parallel jobs, they were able to run all of the tests in around 50 minutes.

Even though they had met the goal, the team wanted to have even quicker test feedback to avoid context switching back to a branch if the build failed 50 minutes later. The team was hopeful that over time, by manually parallelizing tests, they would bring the build time to around 25 minutes.

“Using parallel jobs, we organized testing files into folders that were loosely based on feature and were able to run all of the tests in around 50 minutes total. While we had met our goal, we wanted to have quicker test feedback for our branches so that we would not need to context switch back to a branch if the build failed 50 minutes later.”
Kendal Miller, Senior Engineer at par8o

At some point, they managed to have all tests running in around 30 minutes. However, manually organizing the tests into folders was tedious, because naming the folder in a way that made sense to other developers was hard. They were then required to merge the branch containing the new folder organization into all of the other branches currently in development. Finally, they would add a new job in Semaphore to run the tests in the new folder(s). There was also the risk of adding a new test folder, but not adding the job to run tests for that folder, which would result in a build not running all of the tests. If a new folder was added to try to prevent this, they had a test that failed with an error.

So, even though the testing time was drastically reduced, manually setting up parallel testing was tedious and time-consuming. Enter Semaphore Boosters.

The Solution

As par8o team has been using Semaphore, they’ve interacted with Semaphore support to request new features or updates to packages used by the builders. At some point, Semaphore support offered a solution to reducing par8o’s build time that was averaging 50 minutes at the time.

The solution was Semaphore Boosters — a Ruby gem that records test times for a given file and, using this timing information, splits up the tests into multiple commands based on how many jobs you want to run. The goal is for each job to take approximately the same amount of time to complete. Semaphore currently supports Boosters for RSpec and Cucumber tests.

The manual parallelization strategy was working, but it was fragile and required periodic reorganization of test files as a job began to take too much time to complete. par8o’s slowest tests were the RSpec browser tests, and since Boosters is available for RSpec, they decided to try using them.

The Results

After adding Boosters, par8o’s build time for the entire test suite averages around 13 minutes. Boosters is letting the par8o developers get results for their test suite faster, and they’re also saving time they previously spent moving files around to spread tests across builders.

Getting faster feedback from tests has made it less likely that developers will need to switch to another task while waiting on tests. If the build fails, they can make the necessary fixes more quickly, while the changes are still fresh in their mind. This saves us time and mental energy, while allowing developers to focus on completing the initial task.

With very little effort, the par8o team was able to parallelize RSpec browser tests so that the average run time dropped from over 2 hours to 13 minutes. If you’re using RSpec or cucumber for your tests, give Boosters a try.

More customer stories