Ruby
Article

Sailing the Parallel Seas with Codeship

By Glenn Goodrich

This article was sponsored by Codeship. Thank you for supporting the sponsors who make SitePoint possible.

title

Ahoy, matey! Looks like you’re one of our ilk, a navigator of the beautiful and treacherous seas of software development. We of the SitePoint fleet are always keen to meet another software sailor. Today, we have a special treat for our fellow travelers of the briny deep. The sea folk at Codeship (Codeshippers!) have created a new way to navigate the waters of Continuous Integration and Delivery. One that may be as significant as any development since dedicated unit-testing fleets. It’s called ParallelCI and it will make your ships' jouneys shorter and faster.

A Little Software-itime History

There’s a great chance that you are using some kind of Continuous Integration and Delivery platform. Codeship is “Continuous Delivery Made Simple”. If you don’t know what Continuous Integration and Delivery means, SitePoint and Codeship have you covered:

The seas of software are ever-changing. Platforms like Codeship enable your fleet to adjust to changes in the weather. Read the aforementioned scrolls (linked articles) to learn how Codeship can turn your haggard crew into a powerful armada. Then, come back here to read about their latest navigational offering.

1_codeship

ParallelCI: Cover the Testing Territory Faster

It is possible to run your voyages (builds) in parallel. There are legends of previous explorers sending mulitple ships in multiple different directions to cover the most territory and find the best route as quickly as possible. Before today, this was a very difficult undertaking. Someone would have to create each course (VM), repeating arduous setup and prepartion, and ensure that the courses didn’t cover the same territory. In most cases, the setup was too difficult and the course too expensive, leaving you between a rock and a hardplace. As such, one ship is used to travel all territories.

With ParallelCI, a new offering from Codeship, it is now trivial to create a new course, called a "pipeline". Each pipeline gets the same setup, but then can travel its own course (run its own commands). Now, you can easily break up the Testing Territory into smaller routes, allows each pipeline to sail through less waters. Ultimately, your fleet (software) arrives at its destination (The coveted lands of Deploymentistan) much faster.

Preparing the Voyages

Sign up for Codeship

Since we’re experienced navigators, we’re going to sign up via Github. If your ships are in port elsewhere, you can sign up with Bitbucket or plain email. Github will ask you to allow Codeship to access your ports (repositories) and then greet you with a proper maritime greeting:

Choose a Fleet

Click on the giant green button to create your first project. Captain Mo joins your crew to help prepare you for your first voyage.

Click on the port (repository hub) where your fleet is docked, in this case, the Octocat (There’s a legend telling of Octocat as a Goddess of Software Ports):

A list of your fleets (repositories) will be displayed.

In our example today, I only have a single fleet called Discourse. Discourse is an open source, large fleet that runs on Rails, a very popular manufacturer of fleets. I wanted to use a fleet that is large and has many tests (Discourse has over 4000), so I forked their fleet.

Plot Your Course

Caption Mo now takes us to the main navigational area of our trip with Codeship:

First things first, each voyage will require similar setup commands and tasks. As leader of your trip, you can type in any setup command you require and it will be executed by Codeship’s swabs. Lucky for us, our fleet runs on Rails. Codeship already has common setup tasks for well-known frameworks, like Rails:

Choosing Rails from the dropdown populates both the “Modify your Setup Commands” and “Modify your Test Commands” boxes. Being an experienced navigator, I know that the Discourse fleet needs a bit of a different setup, so I make my modifications:

The setup is the easy part. When we sail into testing waters with Codeship and ParallelCI, that is where the new territories lie. Codeship has suggested that we run bundle exec rake as our Test Command, which I know to change to bundle exec rake spec for Discourse. However, this will take the same, old route through testing. Discourse is a mature fleet that travels through specific testing seas, so we’ll want to do some custom navigation to make the trip as short as possible.

Here are the testing waters that Discourse travels:

Some of these waters are vast, such as components, controllers, and models. Other seas are easily navigated, such as helpers and integrity. My navigational experience tells me that the larger seas will get a dedicated ship (pipeline), while several of the less treacherous waters can be grouped together and covered by one ship.

Also, as an old seadog, I know we’ll want to know how long the traditional, single ship approach takes. That way, we can benchmark the new way and quantify our gains. Benchmarking is foundational to successful seafaring.

During my test run in local development waters (my development machine), I had to flip the hourglass 11 times (so, 11 minutes) during the test voyage. Navigating using Codeship with just a single ship, the test waters were traversed in just over 5 hourglasses.

Now, time to split the test seas into pipelines. Adding a new pipeline is a easier than swabbing the deck. Simply click the “+ add new pipleline” link and you’ll be prompted to name the pipeline:

14_addpipeline

The generous folks at Codeship allow us to create up to 10 pipelines, but the actual number allowed will be based on your account level when the feature is out of beta.

You can see the ships I have created here:

15_allpipelines

With our navigational routes all planned out, it’s time to hit the high seas! A voyage is launched by pushing a change to the fleet (repository). A simple change to the README (which I can edit on Github directly) will do it. Anchors aweigh!

Now that I have a new change, the project page (click on the project name in the upper-left corner of Codeship) shows a new voyage underway:

Back here in port, it’s now a matter of walking the widow’s walk and waiting. Looking at the voyage we can see each of our ships navigating its specified route. As each ship returns to port, you’ll see an indicator on the build dashboard. When they’re all back in, the build is done.


19_pipelines2

When all the ships are back in port (meaning, they’re green), our voyage is at an end:

20_pipelines3

So, how’d we do? It looks like we cut our time at sea by more than half!

21_result

That is incredible. With the blunt instrument of simply assigning a pipeline for each spec folder, we doubled how fast we can get to our deployment destination. HIP! HIP! HORRAY! Rum for everyone!

A Note About Deployment

Once a build has multiple test pipelines it uses multiple virtual machines (VMs) to complete a successful build. As a result, deployment cannot happen until all test pipelines pass successfully. The Codeship UI will give a visual separation of the multiple test VMs and the Deployment step in this case. An example will help:

22_deploy

As you can see in the screenshot, the "Deploying" step runs the actual deployment commands after all the test commands have completed. You can see more about this in this video by Codeship.

Conclusion

ParallelCI is a simple yet very useful addition to the Codeship offering. While the navigational routes we used today were a bit blunt (a pipeline for each spec folder), I am sure you can imagine smarter ways to split up your tests. For example, using something like the parallel_tests gem and it’s —only-group parameter, the specs could be split up based on size.

Regardless of how you do it, using ParallelCI will reduce your test execution time and give you more time to focus on shipping features. As shipping magnate Aristotle Onassis once said “We must free ourselves of the hope that the sea will ever rest. We must learn to sail in high winds.” Codeship helps you learn to do just that.

Codeship offers 100 builds/month and 5 private projects for free to get started easily and without risk, so only a scalawag would put off signing up any longer. Also, the sailors at Codeship are constantly discussing new navigational techniques on their blog. Bon voyage, my maritime friend. Head over to Codeship and give ParallelCI a try now.

Free Guide:

7 Habits of Successful CTOs

"What makes a great CTO?" Engineering skills? Business savvy? An innate tendency to channel a mythical creature (ahem, unicorn)? All of the above? Discover the top traits of the most successful CTOs in this free guide.

Comments
jdickey

One thing I didn't see mentioned was that CodeShip offer their service free for open-source projects, but limit them to a single pipeline. Otherwise, a very nice advert for a great service that we've been happy with for several months now.

ruprict

Thanks for the @jdickey! It's a great clarification.

Recommended
Sponsors
Because We Like You
Free Ebooks!

Grab SitePoint's top 10 web dev and design ebooks, completely free!

Get the latest in Ruby, once a week, for free.