Moving To A More Elastic Future: Upcoming Build Infrastructure Migration

Hiro Asari's Gravatar Hiro Asari,

Over the past couple of years, our growth has changed dramatically and with it, our demands on the infrastructure we're using. Daily build utilization has grown from some 7000 jobs per day in 2012 to now more than 270,000 jobs.

As Travis CI grew, so did our need for computing capacity. In 2013, we found the best option to evolve beyond a VirtualBox-based infrastructure was a private cloud infrastructure based on OpenVZ and that infrastructure has helped us immensely in growing and expanding over the last 2.5+ years.

But as the ecosystem of public cloud providers has grown, the available options for utilizing a purely elastic capacity have too. Earlier this year we began experimenting with using Google Compute Engine (GCE) for running our fully virtualized Ubuntu Trusty builds and we've had great success with it. Some of GCE's features, like a 10 minute billing minimum, and per minute after that and their preemptible instance support, have proven to be an excellent fit for Travis's workload and because of that, we're taking the next step in moving towards a more fully elastic world by migrating our sudo enabled Ubuntu Precise builds over to GCE as well.


Starting in the first week of December 2015 (next week!) we'll begin the process of migrating the entire workload off our OpenVZ platform and onto out new GCE setup. This migration will proceed approximately as outlined below:


  • (public) builds will begin on Tuesday, Dec. 1, 2015
  • (private) builds will begin on Thursday, Dec 3, 2015

Details for (public) builds

Date Action
01.12.2015 We'll begin routing up to 10% of all Legacy Precise builds.
03.12.2015 We'll begin routing up to 50% of all Legacy Precise builds.
07.12.2015 Our goal will be to have up to 100% of Legacy Precise builds running on GCE by the end of the business day on Dec 9th, Pacific time, depending on regression support requests.

Details for (private) builds

Date Action
03.12.2015 We'll begin routing up to 10% of all Legacy Precise builds.
07.12.2015 We'll begin routing up to 50% of all Legacy Precise builds.
09.12.2015 Our goal will be to have up to 100% of Legacy Precise builds running on GCE by the end of the business day on Dec 9th, Pacific time, depending on regression support requests.


This is migration should be mostly transparent. As we begin to route builds to the new infrastructure, you'll be able to tell if your build is running on the new infrastructure because you will see something similar to the following near the top of your build log (in particular the image name in the instance:, e.g. travis-ci-python-precise-1448037712):

Worker information
hostname: travis-worker-gce-org-prod-2:011c873a-832c-4337-8f7b-33f9ef
version: v1.2.0
instance: testing-gce-f32f9cf5-8b5c-42a4-8fc7-7c5a61e0ae8e:

We've done our best to ensure that software installed in the build images on GCE are identical to the existing build image on the previous infrastructure, but there may be some changes due to updates in Ubuntu provided packages or tools that were installed from Github by our chef cookbooks.

IPv6 no longer present

The major change that is coming with this migration is that local and external IPv6 networking will no longer be present. This has been present and while technically not considered to be a feature, it has been available. With the move to GCE this will no longer work, until such time as as GCE adds IPv6 support. We do understand this may cause a disruption for some use cases and while we have considered numerous ways to try to provide IPv6 in the cloud, none of the current available options are suitable for a large production deployment. We ask for your understanding and patience with the fact that is will no be supported for the near future.

Try it now?

You can opt-in to trying out your builds on the new infrastructure by reviewing the steps outlined here

If you see any issues

Our support and infrastructure teams will be giving primary focus to any regressions that may be experience during this migration process.

If you see problems with the new infrastructure's Precise image as we begin migrating, please open a GitHub issue with [precise-gce] in the subject or email and include [precise-gce]in the email subject line.

Updates to containerized builds?

Since the new Precise images on GCE do include some updates, we're planning to update the images used in our containerized builds to match, shortly after we get to 100% in the migration. Look for a blog post announcing that and details on what changes will be included in the update.

Happy testing!

Docs are now served over SSL

Hiro Asari's Gravatar Hiro Asari,

We have been serving our documentation and blog on GitHub Pages. This arrangement was convenient; just push to a GitHub repo's gh-pages branch, and it was live.

This has served us well over the years, but we wanted to serve it over SSL from our custom domain.

To make this happen, we needed to modify the application into a standalone app that can be served on Heroku.

How did we do it?

Using Puma

GitHub Pages sites are served with Jekyll, which comes with a built-in server script. This is handy for local development, but it may not be appropriate for production use.

So we opted for using Puma.


To serve a Jekyll site with Rack, which Puma uses, we add rack-jekyll to Gemfile:

gem 'rack-jekyll'
gem 'puma'

Puma needs to know how to serve this app, so add a new file

require 'rack/jekyll'
require 'yaml'

This is a very straightforward configuration suggested by rack-jekyll.

Test locally

Now, confirm that Puma can serve the app:

bundle install
bundle exec puma

Configure deployment to Heroku

Assuming that you have created a Heroku application to deploy this application to, we need to make two more changes to our application.


Our application will run as a web Dyno, and it is defined in Procfile as:

web: bundle exec puma -p $PORT

Rake task assets:precompile

In order to serve static sites like ours, Heroku's default buildpack expects to have a Rake task named assets:precompile.

For Jekyll sites, it just needs to execute jekyll build:

namespace :assets do
  task :precompile do
    puts `bundle exec jekyll build`

Be sure that Rakefile can load all the tasks

This might seem obvious, but it bears mentioning explicitly.

Our docs app runs HTML::Proofer to check broken links when commits are pushed to GitHub. This is done via Rake, and the gem was installed only in the :test group.

As a result, rake assets:precompile failed to run until the gem was installed in all groups.

Redirect HTTP to HTTPS

As mentioned in the beginning, our goal was to serve the documentation over SSL. It is, then, vital that all HTTP traffic is redirected to HTTPS so that transition is transparent to users.

To achieve this, we use Rack::SslEnforcer.

Adding this is also straightforward:

Add to Gemfile

gem 'rack-ssl-enforcer'

And to

require 'rack-ssl-enforcer'

use Rack::SslEnforcer, :except_environments => 'development' # before `run`

Deploy, sit back and enjoy!

Head on over to! You will be happily redirected to, and know that we stand behind the document you are viewing.

If you find incorrect information, though, please open a GitHub issue at, or better yet, suggest improvements by opening a pull request for

Happy testing!

Magnum Is No More, Long Live Travis CI!

Mathias Meyer's Gravatar Mathias Meyer,

More than three years ago, we launched the private beta for Travis CI for private projects. Since then, our platforms for open source and private projects have been running separately.

Magnum PI
Most prominently, our platform for private projects was using the ominous subdomain, having a landing page that was separate from the app.

Why Magnum? The mustache is a rather prominent feature in the history of Travis CI, you only need to look as far as our mascot. Also, some of us have been sharing a great passion for tv shows from the eighties. Combining that with a passion for mustaches made for a great opportunity to reference Magnum P.I., who does sport a magnificent mustache.

Today we’re saying Good Bye to Magnum, our trusty old friend, by launching a brand new landing page for private repositories.

All your repositories now live on, which means no extra steps required to sign in. If you return to the site, you’ll be logged in, and you’ll be seeing your repositories.

all new pro landing page

This is another step we’re taking towards a unified testing and shipping platform for both private and open source repositories, but that’s a story for another blog post.

Happy testing!