Continuous Integration Workflow

2.1 Travis CI Overview

Hi, welcome back to Continuous Integration Workflow. In this lesson, I will give you an overview of the Travis CI interface and configure our project to be tested there. This is the Travis CI website. You can find the link in the lesson notes below. To use Travis CI, you first need to authenticate yourself with GitHub account. If you're already signed in to GitHub, you won't notice anything happening. After your first login, you will be presented with a very blank view. To add a project, click the plus button on the left besides My Repositories. On the right side of the page, you'll see all your public GitHub projects, and those you've got access to from your organizations. Travis CI was primarily built for open source projects, and is therefore free. But there is Travis CI Pro as a commercial option. The server syncs to GitHub repositories regularly, but if you just added a new project that isn't listed here yet, you can use the sync button to force a sync right now. To enable Travis CI on a project, just use the switch besides the repository name. Once it has a green checkmark, you can go to the repository's Travis page, for instance by going to Settings, the little clock wheel right next to the name. The options in the interface are very limited. You are expected to configure Travis through a YAML file. We'll do just that in a moment. As you can see, you have just four options here. Three of them telling when to do a build, and the other one to limit concurrent jobs. This might come in handy when you have external services limiting the number of connections, or other race conditions that might occur. You can also set some environment variables that will be available to you at build time here. In Travis, you have a few different views to your builds. You can view your pull request builds and complete build history, the builds for your branches, and the very latest build. Right now, they're all empty, since we first need to make a change to our repository to start a build. Let's do that with the GitHub inline editor. We are going to add a file, the travis.yml configuration file. Here, we can specify all the options for our builds. First, we specify the language. We're going to use Ruby. Then the specific Ruby version, using RVM. You can put a list here, and that is exactly what we are doing. We want to test against mri 2.2.0 and jruby, and let's also add 2.1.0. Then we need to specify the Postgres add-on. You can use different services and add-ons like Redis, MongoDB, and Riak. We want the latest Postgres version, 9.4, here. To properly use Postgres, we also need to create a before_script to create the database. And copy a database.yml file from our repository that has the correct Travis configuration. The Postgres user on Travis CI has no password. Let's commit these changes and create a new branch in the pull request for it, so I control all the types in the interface. Now we also need the specific database.yml file before we can test the builds. Change to the add-travis branch, go to the config folder, and add a new file. Its name is database.yml.travis. It only has one environment in it, the test environment. The rest is standard Redis database configuration. Commit the file and go to the pull request. Travis has picked up the changes and started the build. This is indicated by the colored dot besides the commit. Let us look at it on the Travis CI website. On the left, you can already see that the build is running. When you refresh the page, the current tab will show this build. There is an error that .travis.yml file wasn't found. That's right, I forgot that the filename has a dot in front of it. Let's fix that on the GitHub page. Done. You can see another dot besides the commit and the pull request. When I refresh the current page on the Travis CI site, a new build will show. It also shows three build jobs, one for each Ruby version. Running these will take a few minutes. I'll speed it up for you. The build is almost done. You might have noticed that the build number changed. Since Travis also builds pull requests, it not only tested our branch, but also our pull request. When you visit the pull request step, you can see that the first try on running the pull request failed. The second one is almost done. When you click on a specific job, you can follow the output live. It is currently installing all the gems from our gemfile. The button on the top right, that's your follow the log file, so it automatically scrolls, and you'll always see the end of the log. This project has no tests yet, so it shows zero examples. On the left side, you can already see that the build failed, so let's see what happened. The MRI builds passed, but JRuby failed. Right, we didn't adapt our Gemfile to use the proper channels for JRuby. Since this was only a demonstration, I'm going to remove the additional Ruby versions, and just use 2.2.0. While we let the project build, I'm going to show you another cool feature that is used by many projects, matrix builds. I'm going to show this with a Rails project. You can search for other projects with the search field in the top left corner of the page. And you can see the Rails project has a lot of jobs for a single build. This is because it has to test different ActiveRecord adapters, and because it splits up its different gems into separate jobs to see what exactly failed and to make the test runs take less time. Rails also tests against two different Ruby versions, Ruby 2.2.3 and the latest head. Let's look at the Travis configuration to see how it's done. As you can see, there is a matrix list inside the environment section. Each of these values will be run against all Ruby versions, creating a test matrix. For open source gems, this feature is a very important one, since you might need to support many different combinations of versions. Now let us see what the pull request is doing. It passed, perfect. When I check, as GitHub calls it, passes, it shows a green check mark. Those checks cannot only be built, but also called quality reports or similar tools. To finish up, let's merge our pull request, and delete the obsolete branch. When we visit Travis CI one last time, we can already see it building the master branch. In the next lesson, we're going to develop a feature of our application using Git Flow. See you there.