My project at school this last week was to work with a team on an established Rails application in the same fashion we would if we were working together on the job out in the real world. We had to submit and comment on pull requests as each of us built out a feature, did research, or attempted to chase down a bug. I undertook the task of implementing Travis CI, something I thought was going to be very simple and only take a day, maybe two. In retrospect this whole thing WAS very simple, but figuring out what I needed and how to string it all together the first time was a bit of a headache. So I'm going to lay out the basic steps here in a hopefully more straightforward and helpful manner than what I myself encountered.
But first, what am I even talking about? Well, the 'CI' in Travis CI stands for continuation integration, a development practice in which each time a pull request is submitted on Github the code is checked against an automated build and tests are run automatically. The idea behind it is that any issues will be caught early on, before a branch is merged into master. My favorite part is that I often forget to run my test suite before pushing up my code, so it's nice to have that check in place.
The first thing you want to do in order to add Travis CI to your project is
sign in to Travis with your Github account.
If you then go to your accounts page and click Sync account you
should be able to look at all your repositories. There will be a little toggle
switch next to each repo - flip the switch on for any repos you want to be
able to talk to Travis. You will also have to go to that repository on Github,
click Settings, then Webhooks & services, and then
Add service. In the dropdown menu, type in Travis CI,
select it, then click Add service again - it's the green
button at the bottom of the page.
The next thing you will need to do is add a .travis.yml file in
the root of your application. This file is how we configure Travis CI - it will
specify the language of your app, the desired building and testing environment
(which includes any dependencies that need to be installed before the aforementioned
building and testing can happen), and a whole host of other custom parameters.
This is the point at which you need to figure out what to put in your
.travis.yml file. There are some excellent starter notes
here.
This part is very individual and customizable, and I've only personally
done it once, so I can't tell you more than what I figured out for this particular
project - you'll just need to do a bit of EDD (Error Driven
Development in the form of build errors from Travis) to figure out if what
you have is working. But I can provide some general guidelines:
The .travis.yml file can be very simple or quite complex depending on
what your needs are. Mine ended up being really simple once I figured it all
out - and I think this is probaby the case for most apps
You can look at my file here.
You will need to specify the language of your application and what versions of that
language you want Travis to test against.
I didn't need to install any dependencies, I just needed to set up the database
and provide some basic information about the test environment. Information
about setting up your database can be found here.
These are the services and before_script lines in my code
example from above. If your project needs to run something other than rake
you will need to add instructions in a script section. You will
see in my code I added the command to run an RSpec test suite. The last piece
I needed in order for my test suite to run properly in Travis was to specify
travis_ci_test as the test database in my config/database.yml
file here.
NOTE: If you are using PostgreSQL and you find that your tests are
failing locally after integrating Travis, try running rake db:test:prepare
from the command line. This will prepare your new test database.
From what I understand those are the bare minimum necessities needed for Travis
to do a build. After that there's a ton of custom stuff you can add as you desire
You can get build notifications on Slack (the default is for the email associated
with the repo to get these) or encrypt sensitive data.
Check out the docs if you're interested.
I choose to add in the Coveralls gem for
test coverage. This was just a matter of adding gem 'coveralls', require: false
to my Gemfile and after_success: coveralls to .travis.yml.
The last fun thing I added in was status icon badges. These are the little icons that say "build passing" and "coverage 91%" at the top of my README. Instructions on how to do this for Travis are here and it works exactly the same way for the Coveralls test coverage badge.
You also may want to check out the Travis command line client
I'm not sure of the full use of this yet except that it allows you to run
a whole bunch of helpful queries from the command line such as travis help
(shows you all the commands you can use to gather information) and travis branches
(displays the most recent build for each branch). One of my favorites was
travis lint which checks your .travis.yml file for
any errors. Pretty neat!
When I set out to add this feature I said something to the effect of "this is the kind of thing that will be really complicated the first time, end up requiring very little code, and then super easy in retrospect" and that's exactly how I feel. The next time I implement Travis it will be a complete breeze, I could do it with my eyes closed. Hopefully this write-up will help your first time be a breeze as well. Happy coding!