Continuous integration with Laravel and Travis CI


Developers are inherently lazy. A good lazy developer will always try and find the simplest solution to a problem and make sure it’s tested and formatted correctly so he never has to spend time on it again. A bad lazy developer will haphazardly copy and paste whatever works with a slapdash attitude showing no pragmatic thinking at all. Fortunately, Laravel developers at fastfwd are all perfect; we never make any mistakes. However, we still like to have some fail-safes in place in the unlikely event a developer becomes complacent.

Tools we will use

Github version control.
Travis CI continous integration server.
Laravel our PHP framework of choice.
PHP CodeSniffer detects violations of a defined set of coding standards.
PHP Unit testing framework.
JSHint a JavaScript Code Quality Tool.

Continuous integration – the practice of frequently integrating one’s new or changed code with the existing code repository – should occur frequently enough that no intervening window remains between commit and build, and such that no errors can arise without developers noticing them and correcting them immediately.” – Martin Fowler.

Connecting your repo to Travis CI

At this point, I am assuming you have a Github repository which contains a recent install of Laravel 5.4.
To connect your repository with Travis, click on settings > Integrations & Services and Add a new service for Travis CI.

In Travis CI, you must add your repository…

…and choose to only build if you have a .travis.yml in your root directory.


We need to create a simple travis config for the build process, so add this to your root

  - linux

language: php

  - '7.1'
  - composer self-update
  - composer install --no-interaction
  - cp .env.travis .env
  - pear install pear/PHP_CodeSniffer
  - phpenv rehash
  - nvm install 7.7.1
  - npm install [email protected] -g
  - npm install -g jshint
  - npm install
  - vendor/bin/phpunit --coverage-text
  - phpcs --ignore=app/Http/Controllers/Auth,app/Http/Controllers/Controller.php app/Http/Controllers
  - npm run production
  - jshint resources/assets/js/modules/*

So what does this do?

It will spin up a virtual machine inside travis and perform the following operations before we run any tests (via the before_script).

  • Installs a linux operating system
  • Installs PHP 7.1
  • Runs composer on laravel and copies over the .env file
  • Installs PHPCodeSniffer
  • Updates Node to 7.7.1 and Npm to the latest version
  • Installs JSHint

Once the virtual machine is setup it will:

  • Runs our unit tests and output a report on code coverage (should always be 100% right?)
  • Runs PHPCodeSniffer and reports on any undocumented code or violations in coding standard (Laravel follows the PSR-2 coding standard and the PSR-4 autoloading standard)
  • Compiles our assets (JS, SASS, CSS etc) using Laravel Mix
  • Tests for any Javascript violations

What it doesn’t do

Laravel has just changed from Elixr (gulp based) to Mix (Webpack based) and I couldn’t quickly figure out how to run SASSLint so I could not test the SASS.


Now, every time you push a commit the CI server will run the build.
GREEN – Build Passed
ORANGE – Build running
RED – Build Failed!

You can add your badge of honour (or shameful fail) to your repository with the following markdown:

[![Build Status](](

You are now forcing your developers to write code that passes all the basic tests.

What else can we do from here?

Travis has built-in notifications, so we can, for example, notify the team via email and Slack. In your .travis.yml add:

    on_success: never
    on_fail: always
    - [email protected]
    - [email protected]

You can find more information on notifications HERE

One step further

Check out Travis status board to setup a status board for the office. Run it on a large screen to have an instant overview of all your builds.

Then there are traffic lights…
You could set this up on a Raspberry Pi with audible alerts as well as visual alerts. But thats a project for another day.


Use continuous integration to prevent bad lazy developers ruining your project.

Insights by Trevor Sewell

Share this post