How do you prove your tech works? You can write a test suite, but how do you demonstrate that it works to others?
Enter Travis, a continuous integration service. Travis uses Github webhooks to run your project’s test suite whenever you push new changes, thus demonstrating the health of a project’s code and answering the fundamental question, “Does this thing even work?” Let’s see how!
This is the first post in a series in which I’ll demonstrate how to use continuous integration services like Travis to communicate code correctness to your users and automate tasks like deployment and status notifications. In this first post, we’ll cover how to get started with Travis on a Node.js project.
Travis watches your project’s repository for new commits. Whenever it sees one, it runs the test suite, along with any other instructions you might give it, on a machine provided by the community (thus eliminating any “well, it works on my computer” problems early). If the test suite passes, hooray! If it doesn’t, you’ll get an email letting you know something went wrong.
The easiest way to get started with Travis is with its command-line interface. To get it, you’ll need Ruby installed. After, use gem to install the command-line interface, like this:
gem install travis
Great, now we need a project to integrate. If you have a project hosted on GitHub, just navigate to that project’s folder in terminal, and run travis init, like this:
cd ~/your/project/path travis init
This does two things:
- Tells Travis to begin watching this GitHub repository for changes.
- Creates a .travis.yml file.
The .travis.yml file instructs Travis how to run your test suite, what to do before and after, what versions of your language to use, and other options. By default, a Node.js project will have a .travis.yml file like this:
language: node_js node_js: - '0.11' - '0.10'
This informs Travis that this is a Node.js project and that Travis should test it with Node.js versions 0.11 and 0.10.
But wait, where do we tell Travis how to run our test suite? If you run your test suite with npm test, you already have. Travis uses sane defaults to minimize the effort of integrating, if you’re already following community best practices. For more details, check out the docs.
Now, whenever you push new commits to your project, Travis will execute npm test using Node.js version 0.11 and 0.10. If either version fails the test suite, the build is considered failing. If both pass, hooray!
Say your project uses Orchestrate, and so your test suite needs access to an API key to work with the database. How do you give Travis your API key, securely? Use travis encrypt! Check it out:
travis encrypt ORCHESTRATE_API_KEY=YOUR_API_KEY --add
This will encrypt your API key and add it to your .travis.yml, so to anyone except Travis, it looks like gibberish:
language: node_js node_js: - '0.11' - '0.10' env: global: secure: bBJ1lQqjw6ifKx26/tWfz6grXBehnjbJAr9qrgIW6iCFlooDXNGIUQRp0wQTNwwUZsKlp2dCTcPrYHVGwqzh21V6r9ejkbkO+z9ZUrXs4HQxPd+P8mjXIccH5f6Cac/kC2EglWW+/T+KwiqLBAJs3p9xJe9SUby6WgyBL/u34mg=
Now, whenever Travis runs your test suite, the environment variable ORCHESTRATE_API_KEY will contain your API key. Use this pattern to pass your test suite the credentials it needs without putting them straight in your code.
For visibility’s sake, Travis exposes a status image that publicly states how the latest build performed. To get your status badge, go to your project’s Travis page, and click on the badge there. It will present you with a dialogue to generate the code for your badge. For example, this badge comes from Porc:
Put that badge in your project’s readme, and now viewers can know at a glance that your project works.
Or can they? Next time we’ll discuss using Coveralls, a code coverage service, to demonstrate just how robust your project is.