All

Continuous integration with Laravel and Travis CI

long-exposure-3

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.

.travis.yml

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

language: php

php:
  - '7.1'
  
before_script:
  - 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
  
script:
  - 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.

THE MAGIC

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](https://travis-ci.org/your/repo.svg?branch=master)](https://travis-ci.org/your/repo)
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:
notifications:
  slack:
    on_success: never
    on_fail: always
  email:
    - [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.

TLDR;

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

Insights by Trevor Sewell

Share this post