← Home

Travis - a distributed build server tool for the Ruby community

So, I’ve started playing with the idea of a distributed build server tool once again in last year’s December … and Travis is what I came up with.

Status quo

  • Travis is currently running on http://travis.heroku.com and already notifies me about builds that pass or fail when someone pushes to those repositories I’ve registered for testing purposes.
  • The builds run on a virtual server that Julian Fischer has very kindly granted for this experiment.
  • The frontend is implemented using Backbone.js.
  • Build output and status information is “tailed” from the workers to the frontend (i.e. browsers) using websockets via Pusher. It is also pushed back to application (running on Heroku) using a standard REST API.

All of these building blocks might change in the future, but here’s an overview of how they currently work together. And here’s a short screencast (the UI has changed a bit in the meanwhile but you’ll get the idea): 1:20 quick demo screencast

The vision

Maybe Jenkins CI (formerly Hudson) is the best open-source build server tool for Ruby projects out there today and everybody seems to be using it. Or maybe that’s just my impression. In any case my feeling is that it just isn’t a particularly good fit to the Ruby community for a couple reasons.

Instead, imagine a simple and slim build server tool that is maintained by the Ruby community itself (just like Gemcutter is, or many other infrastructure/tool-level projects are) in order to support all the open-source Ruby projects/gems we’re using every day.

Why not have a very slick application that loads off all the heavy work to workers – and have workers started on boxes contributed by the community itself. A lot of people have underused boxes idling at their offices or somewhere else. Why not make it easy for them to contribute run-time on these boxes for building open-source Ruby projects they use every day. I am sure many people would love this kind of opportunity of giving something back. On top of that one could even post a tiny message alongside with builds that ran on their boxes (a la “this build was kindly sponsored by [link to their website]”) to make this even more appealing.

A system that uses a client-side JS frontend, websocket messages and a tiny JSON API will make it easy for people to come up with alternate UI implementations. The current implementation of Travis should already allow building a custom dashboard or mobile app pretty easily.

I have no idea whether this will actually happen. But the vision of building an open-source build server infrastructure that is as much community-driven as Gemcutter is, allowing the community to contribute the required computing resources in order to build projects they love and use … really fascinates me.

Please join and help

My first goal with this experiment was to build a simple system that already makes sense as a stand-alone, privately maintained tool for running private builds in a closed environment and as such it seems to work quite fine so far.

Now I think the next step should be to get you involved :)

Please get on board and help pushing this project. E.g.:

  • Register to the Google group and share your opinion
  • Pop in to the IRC channel irc://irc.freenode.net#travis and say hi
  • Try out the application on http://travis.heroku.com, sign in and set up a service hook for some of your open Github repositories.
  • Review the code and tell how to improve, e.g., the client-side JS application, the EM-based worker code, the architecture in general etc.
  • Have a look at tickets filed on Github, discuss and help resolving them.
  • Share ideas about how to improve the UI design (I think the current minimalistic design works for now, but certainly isn’t good. I don’t consider myself a design person, so any input is highly appreciated)
  • Come up with ideas about how to implement a dynamic spin-up of workers on EC2 instances, VMs running workers securely on contributed boxes.
  • Build an alternate websocket service in case we can’t use Pusher.app in future (Travis currently uses a free dev account on Pusher.app and paid plans seem quite expensive).
  • Whatever else you’re interested in … :)

If you have any questions just post to the mailing list or drop me a note via Twitter, Github or email.

Some of the questions that I definitely need some input for are:

  • This is the first single-page Backbone.js app I’ve done. Does my interpretation of JS MVC make sense? Should I change the way views are instantiated and/or bound to events?
  • How to dynamically spin up workers in VMs on EC2 instances or other boxes?
  • How to improve the websocket message flow from workers via Pusher to the browser? E.g. sometimes messages arrive at the browser in the wrong order because they’re not synchronized or ordered in any way.

In any case your input is highly appreciated!