Introduction to Travis.CI

Introduction to Travis.CI Part 1

Modern application development is a pretty demanding job, mainly because of the complexity of modern applications, and the sheer number of moving parts which have to be managed.

Whether we’re building APIs, content management systems, or console applications; whether we’re managing a small, medium, or large development team, there’s always a lot to keep track of.

Yes, it’s something which we all do on a regular basis, but that doesn’t make it enjoyable. So how do we keep the complexity manageable so that it doesn’t demand so much of our time and attention, that we’re unable to get on with the core work of application architecture and development.

What tools are around to make it simpler and easier? Good question. One such tool is the subject of today’s post, the open source, continuous integration server – Travis CI.

What is Travis.CI

Travis CI, which I’ll refer to simply as Travis from hereon in, is an open-source, continuous integration server, which works with projects, both public and private, hosted on GitHub.

Supporting a wide range of languages, including C, C++, C#, Clojure, Erlang, Go, and Scala, Travis attempts to build a project and run tests when it detects that one or more commit’s have been pushed to the project.

It has a wide range of features, such as sending notifications, encrypting sensitive data, and build status images, and integrates with a range of third-party services, such as CodeClimate and Sauce Labs.

What’s great about services, such as Travis, is that once they’re setup, they’re largely automatic, and provide near instantaneous notification to development teams, as to the status of the project.

When taken to the extreme, it can form a core part of a continuous deployment process, removing the need for almost all manual interaction in a build and deployment process. Sound tempting? Let’s get started integrating it in to a simple project.

The Travis Build Configuration File

Recently, I created a simple application using the Aura 2.x framework. As the project’s not too complex, and already has a simple test suite in place, it makes a great candidate for integrating with Travis.

What’s even handier is that the original project, from which mine was forked, already has a Travis build configuration file, called .travis.yml, in place. Let’s have a look at it.

yaml language: php php: - 5.4 - 5.5 - 5.6 - 7 before_script: 
- composer self-update - composer install script: - ./phpunit.sh

You can see that there’s not a lot to it. It starts off specifying the language, then the versions of the language to build against. After that, it specifies a series of actions to take before the build takes place, in the before_script section, and when the build takes place, script, what to do, which is run phpunit.sh.

What this is going to do is to create three environments, one for each of the versions of the language specified, and run the tests within them. We could also have configured a range of other options, depending on our needs, including:

• PHP Extensions
• PHP’s Environment Configuration
• PEAR Packages
• Operating Systems
• Deployment Settings

However, for sakes of simplicity, I’m sticking with the configuration shown above.

 Integrating an Existing GitHub Project

As the project’s already on GitHub, we need to login to Travis and enable Travis to work with it, as commits are made and pushed to the project repository. Please follow along with a project of yours. If you don’t already have an account, you can signup and login with your GitHub account.

After you’ve done that, on the right-hand side, mouse-over your name, and click ‘Accounts’ from the dropdown menu, where you’ll be taken to a listing of all the projects in your profile, which you can see a sample of below.

From there, just in case, click ‘Sync’ next to your name to ensure that your project is in the list. With that done, I’ve navigated down the list to the project, where you can see that it’s greyed out, and inactive. To enable it, just click the toggle, which will change to a green tick, indicating that the project’s now active with Travis.

When you’ve done that, click on the Project’s name, where you’ll be taken to the project settings page, which should look like the screenshot below.

There you’ll see that it’s pretty simple, with nothing much happening. Let’s work through what’s available. At the top, you have:

The name of the project
A link to the repository on GitHub
The current build status (set to unknown as it’s not been built before)

Then there’s:

• The current status
• The builds which have been run
• The build history
• The builds for submitted pull requests
• The current settings.

By default, a build will run when a commit’s pushed, even if no .travis.yml is present and there’s no limits on concurrent jobs.

I decided to change this by enabling these two options. At the bottom you can set environment variables, handy if you want to test different environments, such as dev and production, or need to set variables which would be part of a standard request, yet which wouldn’t be available in an environment such as this.

The Build Process

Now let’s make a change so that a build is triggered. In src/templates/data/sales/view.php, I’m going to add a table footer, which simply prints out the number of records retrieved. You can see the code in the screenshot below.

Assuming that we’re working through a standard git workflow, I’ll add, commit, and push the changes, triggering a build. A short while after the push is complete, if you look at the branches tab of the project, as in the screenshot below, you can see that a build’s been triggered, along with key details, such as:

• The commit message
• The commit hash
• The committer
• The build run time
• Triggered build with details

As the build progresses, information about the build jobs will become available. You can see the number of each job, the operating system, the language and language version, whether environment variables were set, and how long the job ran for. This makes it really simple to quickly know the status of a build.

When a job’s complete, you can look at it’s status, to find out specifics about that job’s progress and success. Assuming one failed, by clicking on the job you can see what happened. In the example below, building the PHP 7 source failed, causing the job to fail.

Fixing a Broken Build

Let’s remove that now, as it’s not essential, so that we can make the build pass. Opening .travis.yml, I’ll remove the requirement for PHP 7, commit and push the change to the remote repository.

As before, the build triggers after a short time. This time, the PHP 7 job is no longer in the list. As all the jobs pass, the build is set to ‘passing’, and flagged green to visually show that everything’s OK, which you can see in the screenshot below.

Now this is a simplistic fix to make. It’s fair to assume that the majority of your build failures would be expected to come down to failing tests or different kinds of deployment problems. But for the purposes of a simple example, it’s sufficient.

 Build Notifications

Now this is all great, but how often are we always logged in to Travis and watching it? To be fair, some development companies dedicate a large monitor to the build server status. But this might be overkill for your situation.

So it’s handy to know that Travis provides notifications to be configured, including emails, and such services as HipChat, and IRC. For today, I’m going to setup a simple email notification. To do that, I’ll modify .travis.yml again adding in the following further configuration at the bottom of the file.

yml notfications: email: recipients: -
 on_success: always on_failure: always

What this does is to always send email notifications on both success and failure, and adds a further email recipient, . I say further as, by default, Travis reads the email setting from the project’s git configuration and emails that address.

This setup is handy for notifying extra people. Again, after committing and pushing that to the project repository, when a build is finished, I’ll receive an email, similar to the one below.

This is a sample of a build fail email, which happened when a pull request failed. You can see that it lists the project, the branch, along with a range of details, similar to what you’ve seen earlier.

Speaking of merge requests, let’s look at that feature now.

Pull Requests

Just like standard commits, a build will be triggered if someone submits a Pull Request (PR) from a forked copy of your repository. This saves you, as the project maintainer, the effort of checking whether their PR has broken the build.

Let’s work through a simple scenario. In the image below, you can see that I’m just about to submit a PR against the project. I’ve specified the branches, as well as a short and long description.

After I submit the pull request, back on the original repository, you can see that text from the PR in the timeline of the repository, Travis has added further information indicating that there’s a build in place.

Note: This won’t stop you as the maintainer from merging the changes. You’re still free to do that if you like.

When a PR has been merged, as below, the Travis information is much more subdued. In this case the build’s failed, as indicated by the red cross next to the commit hash of the PR. Mousing over it displays a popup containing a short description of the build failure. Clicking the cross takes you to the build so that you can find out why. Handy!

Build Status Images

We’re almost done with part one of this quick introduction to Travis. But I want to finish up with one final point – build status images. You’ve likely seen on your favourite GitHub projects’ README files status images covering the build status, code coverage and so on.

Travis makes it easy to integrate the build status image with our project, so that all the world can know how great we are. To get that in to our project is quite simple. When viewing your project in Travis, next to the project’s name at the top, you’ll see ‘build passing’ etc, as in some of the earlier screenshots. Click that and a popup appears, as below.

Here, you can get the link text, in a range of formats, and per/build. In this image you can see the link in Markdown format, for the development branch. Copying that in to the README, and pushing it to the project, results in a nice build passing image, which you can see below.

 Wrapping Up

And that’s a wrap on the open source, continuous integration server, Travis CI. From integrating an existing GitHub project, to working through a series of builds, to looking at some handy functions, such as email notifications, and build status images; now you know how to integrate your project with Travis CI, and make your life that much simpler and less stressful.

If you’ve not tried Travis before, I hope this introduction’s given you both a good overview, as well as encouraged you to include it as a start part of your development workflow. Already using it? Share your thoughts in the comments below.

In my next article, we go further by looking at more advanced features, such as:

Notifications via HipChat and IRC
Integration with CodeClimate for quickly and easily understand the health of your codebase
Deploying your code after a successful build
I hope you’ll join me then.