New Deployment Features and Command Line Goodness

Konstantin Haase's Gravatar Konstantin Haase,

Travis CI is moving fast, quickly approaching the 70,000 project mark. To make sure you get the best CI experience, we want to keep you up to date with what’s going on. So here is a few things that landed recently.

Of course, everything described here is available right now to both travis-ci.org and travis-ci.com.

Continuous Deployment

We’ve recently launched built-in continuous deployment support for Heroku and Nodejitsu and have heard back from the first happy users. We’ve looked at your feedback and are happy to tell you about our two new deployment features.

Restarting Heroku applications

Sometimes you need to restart your Heroku application after running some command. One example is running migrations for a Rails application, which only loads the database schema on boot.

You can now simply add restart to the run section of your .travis.yml:

deploy:
  provider: heroku
  run:
  - "rake db:migrate"
  - restart

This also works in between two steps!

Deploying build artifacts

After your tests ran and before the deploy, Travis CI will clean up any additional files and changes you made.

Maybe that is not what you want, as you might generate some artifacts (think asset compilation) that are supposed to be deployed, too. There is now an option to skip the clean up:

deploy:
  skip_cleanup: true
Setting Heroku buildpack

When deploying to Heroku via the Anvil strategy, you can now set the buildpack to use:

deploy:
  provider: heroku
  buildpack: ruby

You can either use a shorthand for the default buildpacks, like ruby or nodejs or give it the full URL for a custom buildpack.

Command Line Tool

Our command line client also got a few new features that should make your life easier. Get the latest version by running

$ gem install travis

If that command doesn’t work, make sure you have Ruby installed.

Initializing a project for Travis CI

If you want to set up a project on Travis CI, you can now run travis init, which will create a .travis.yml with some sane defaults and enable the project, so the next push to GitHub will trigger a new build.

$ travis init
Main programming language used: java
.travis.yml file created!
example/project: enabled :)

The .travis.yml generated from the above example looks like this:

language: java
jdk:
- oraclejdk7
- openjdk6

You can also pass in a lot of options to influence the generated configuration:

$ travis init ruby --rvm 1.8.7 --rvm 1.9.3 --script "rake test"
.travis.yml file created!
example/project: enabled :)
Setup wizard for continuous deployment and addons

When setting up continuous deployment or an addon, you probably spend some time looking at the docs figuring out which options to set and if you should encrypt some of them.

To ease that, we now offer a travis setup command that you can run in your project directory:

[~/travis-api]$ travis setup heroku
Heroku application name: |travis-api|
Deploy only from travis-ci/travis-api? |yes|
Encrypt API key? |yes|

You can also use this for setting up Sauce Connect:

[~/travis-api]$ travis setup sauce_connect
Sauce Labs user: rkh
Sauce Labs access key: ***************
Encrypt access key? |yes|
Improved value encryption

When you add encrypted environment variables, you don’t want to override existing variables, which is why the travis encrypt command turns it into a list if it isn’t already and appends the new value.

However, this causes issues when you re-encrypt for instance a deploy token, as you might accidentally turn it into a list with two entries even though you wanted to override the old one.

Therefore, by default, travis encrypt will only use the former behavior for env values and override the current value otherwise. You can change this via --override or --append:

$ travis encrypt "my secret" --add env.global --override

Keep in mind that using --add requires you to run the command from inside the project directory.

Branch overview and details

Similar to the “Branches” tab in the web interface, you can now get a branch overview in the console:

[ ![travis branches](/images/travis-branches.png) ](/images/travis-branches.png)
`travis branches`
Accessing the public key

You can now access a repo’s public key by running travis pubkey:

$ travis pubkey -r travis-ci/travis
Public key for travis-ci/travis:

ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAAAgQC ...

Like all travis commands, this is pipe friendly:

$  travis pubkey -r travis-ci/travis --pem > travis.pem
Lots of small fixes

There were a lot of small improvements, especially dealing with edge cases and encodings. The documentation and error messages have also seen some love.

Thank you

Special thanks for helping with these features go out to Aaron Hill, Johannes Würbach and Peter Souter. You rock!


More Deployment Goodness: Announcing OpenShift Support!

Aaron Hill,

Remember a little while back when we introduced support for deploying to Heroku and Nodejitsu?

We thought “why stop there”!

We are excited to announce that you can now deploy to OpenShift from your Travis builds!

To set up continuous deployment to Openshift, add the following lines to your .travis.yml:

deploy:
  provider: openshift
  user: "YOUR-EMAIL-ADDRESS"
  password: "YOUR-PASSWORD" # encrypted, of course
  app: "YOUR-APP-NAME" # optional if it's the same as your repo name
  domain: "YOUR-OPENSHIFT-DOMAIN"

Or, if your have our command line tool installed, use the new setup command:

$ travis setup openshift

That’s it!

To provide the best service possible, Travis CI has teamed up with OpenShift as a partner and there is an official Travis CI QuickStart to get you going.

This feature is immediately available to all our users including our Travis Pro customers.

For more information, see the documentation.

Your provider still missing?

If your cloud provider isn’t supported by Travis CI, please let us know.

Or, if you’re so inclined, add support yourself and send us a pull request.


3 Essential Preparation Steps for a Successful Maintenance

Mathias Meyer's Gravatar Mathias Meyer,

We all love shipping code to production fast and with zero downtime.

But while most changes require no downtime to be deployed, there are production changes that require for the entire site, or at least parts of it, to be taken offline for maintenance.

Some database migrations are bigger than others, some component changes are not as fluent as others. For instance, we’ve had to switch our RabbitMQ instance several times.

Unless it was an emergency maintenance, we found that there are some steps that are essential to prepare for an upcoming maintenance, to make sure it’s going as smooth as possible.

1. Announce the Maintenance

It’s important to give your customer notice to prepare for the upcoming disruption. The more bound your customers’ daily workflow is to your product, the more important it is to give enough notice for them to prepare for your site to be not available.

To reduce the impact of bigger maintenances, we tend to move them to the weekends, if at all possible.

It pays to have a status page for this and a feed your customers can subscribe to. For a bonus, include the notice prominently in your application. We use StatusPage.io for this purpose, and we have an internal broadcast system which we use to notify our customers of upcoming disruptions.

Make sure to give updates as the maintenance progresses, in particular if it extends the expected window of downtime.

This is a matter of operational transparency, and a courtesy to your customers.

2. Prepare a Maintenance Checklist

As the maintenance window approaches, sit down and think about all the steps involved for a successful migration. While this doesn’t need to be an exhaustive lists, it’s good to have as many steps as possible in here.

Include steps to prepare maintenance, to carry it out, and to verify that it was successful.

It will not only give you a book to play by, it will give you time to think about every single step and its potential side effects. It also allows you to prepare scripts for steps that lend themselves nicely to be automated during the maintenance window.

Thinking about and preparing for all these details gives you confidence for the task ahead.

I found this to be one of the most important steps to prepare for a maintenance.

3. Find a Maintenance Buddy

Just like handling outages, it’s handy to have another person around. It gives a sense of security, and it gives you someone to sanity check every step of the maintenance with.

On top of that, you can work on the tasks in parallel.

While preparation is key, execution is where the rubber hits the road. Having someone around who can interact with customers, update the status page and run validation commands is very handy.

After the Maintenance: Follow up with a Post-Mortem

Not every maintenance window goes as planned. There may by hiccups, things that have unexpected side effects, and things that go downright wrong and cause an extended downtime.

It’s important to follow up a problematic maintenance with an internal post-mortem. It doesn’t always have to be a public one. We use internal GitHub issues for this purpose.

It’s more important for your team to learn from what went wrong and improve code, infrastructure and procedures accordingly to reduce the risk of it happening again in the future.