PHP and Continuous Integration with Travis CI

Continuous integration (CI) allows a team to commit their work quickly, which means there will be multiple commits to a repository daily. Every time there is a commit it is verified by an automated build (including test) to alert you of any build or test errors immediately. Once the process of integrating and verifying your work into the master becomes automatic you are able to develop cohesive software rapidly.

What is Travis CI?

Travis CI automatically sets up a CI environment and makes it simple for anyone to test and deploy their app. Their build system supports many different languages, you just have to define which language this project is and Travis CI will take care of the rest. You can find more information about all the other environments they offer in their docs, but for this article we will focus on adding Travis CI to a PHP repository on GitHub.

Public repositories on Github can use Travis CI for free, but they share community boxes and sit in queues. To use a private repository with Travis CI you can subscribe to one of their plans and get your project built without waiting, plus you can have concurrent jobs.

Getting Started With Travis CI

Step 1: Sign In

Sign in to Travis CI with your GitHub account by clicking the Sign In link at the top right.

On this page you will see off to the left a list of public repositories being built. To watch their build live just click one of them.

Step 2: Sync Your GitHub Repos

After you’ve signed in Travis CI will synchronize your public repositories to your account under your profile page. You will then need to click the switch button into the On position. Now every time you commit to this repository GitHub will make a call to Travis CI and automatically initiate the build process.

If you create a repository and you do not see it listed click Sync now on your profile page and your newly created repository will appear there.

Step 3: Add .travis.yml file to your repository

To tell Travis CI what environments you want your repository built and tested under you’ll need to add a .travis.yml to the root of your repository. Travis CI will run your tests against a matrix of all possible combinations of your configuration using:

Step 4: Trigger A Build With a Git Push

Your first build must be triggered by a commit and push from GitHub, not the Restart Build button.

Every time you push a commit to a branch on your repository, Travis CI will initiate the build process. Once a worker is available it will start building your project. You can navigate to https://travis-ci.org/GITHUB_USERNAME/REPO_NAME to watch it’s build progress live.

If you want to restart your build, click the Restart Build button and you will see your project start building once a worker is available.

Step 5: Tweaking your build configuration

In the example repository you will find a .travis.yml file that includes the basics with a few extras to some show of the potential Travis CI has. If you want to customize your configuration you can configure almost everything about your build environment.

Step 6: Test it

To see if you configured your repository correctly edit your README.md file on GitHub and commit your edit. Go over to that repository’s Travis CI page and all the circles under Job should become yellow and once the build is running the duration should start incrementing.

Once the build is complete and the light goes red click it and read the output in the console. You can also setup Travis CI to send you an email letting you know what happened via the notifications option.
If your build doesn’t start try validating against a YAML Validator to make sure there are no mistakes in your configuration file.

Quick Overview

Current

All of the builds that you have defined with your configuration options will appear here with a colored icon next to them noting their build status.

Blank screen: You have yet to run your first build

Yellow: In progress

Red: Error, check the console

Green: Success!

Build History

Every time a build is run it receives a build number and creates a history that you can see what commit triggered the build, a link to the commit on GitHub, the duration of the build, and when it happened.

Pull Requests

To give project managers a good idea of whether or not a pull request would break your build, Travis CI automatically builds your project with that pull request and shows it’s status on the PR.

Branch Summary

Travis CI not only builds your master branch but also all other branches and the Branch Summary tells you the current build status of each one.

Conclusion

As you can see, Travis CI is a robust and feature rich service aimed at keeping your projects alive and kicking through any and all contributions. Have you implemented it in your projects? Got tricks to share? Let us know!