Testing and building web apps with Travis CI

Modern web projects are complex - they rely on multiple technologies and third-party services to function.

The management of these projects and their dependencies isn't easy. Gone are the days of uploading a couple of .html files via FTP and hoping for the best.

With business-critical applications, you should strive to minimise any disruption in service. Using a continuous deployment service like Travis CI can help with that by building your project and testing your code before it hits your production server.

Before you push new code to a production site, you want to be confident that:

• all site dependencies are available and installable via our chosen package managers
• we’ve built all our site assets and that they are optimised
• all the tests within our test suite are passing

Getting Started

Before you get started you'll need the following:

• A GitHub account
• An active Travis CI account (you'll log in using your GitHub account)

One of the benefits of Travis is that you store all your build configuration in a single file. You can then commit that file to your project's Git repository.

The anatomy of a Travis Config file

Here’s an example of a basic .travis.yml file.

language: php
php:
 - 7.0
services:
 - mysql
env:
 global:
 - APP_ENV: production
 - DB_USERNAME: root
 - DB_DATABASE: test
 - DB_PASSWORD:
before_install:
 - mysql -e 'create database test'
install:
 - travis_retry composer install --no-interaction --prefer-dist --no-suggest
 - nvm install 5.10.1
before_script:
 - gulp build
script: vendor/bin/phpunit

The file is broken down into logical steps; let’s look at each in more detail.

Language

language: php
php:
 - 7.0

With this chunk, we’re telling Travis we wrote our project in PHP and what version(s) we want to use during our build.

Services

services:
 - mysql

The Travis docs tell us that services aren't started by default. This maximises the amount of RAM available to your build. With that in mind, you should only start services you actually need for your build.

Environment Variables

The environment variables configuration step lets you define your variable values. Once set, they're made available to both your project code and your custom build scripts.

A good example use case is setting your application environment and database credentials.

env:
 global:
 - APP_ENV: production
 - DB_USERNAME: root
 - DB_DATABASE: test
 - DB_PASSWORD:

The Build Lifecycle

before_install, install, before_script and script are all part of the standard Travis build cycle.

before_install:
 - mysql -e 'create database test'
install:
 - travis_retry composer install --no-interaction --prefer-dist --no-suggest
 - nvm install 5.10.1
before_script:
 - gulp build

In the example, we use before_install to create our testing database. The install step installs our preferred version of node along with the project’s dependencies.

In an extended example, you would see npm install, bower install etc. here too.

At this stage in the build lifecycle, you should have all your dependencies installed and can now move on to building your app. Our example uses Gulp to build the production version of the site within the before_script configuration block.

The script block is your opportunity to run your test suite. For example, if you were testing with PHPUnit, your confirmation would be:

script: vendor/bin/phpunit

Note: There are a couple of extra steps in the build lifecycle that we haven't included in our example:

• after_success – will fire when your build passes
• after_failure – gives you the opportunity to run scripts in the event of a build failure

At this point, your project has been built and tested, which means it's safe to deploy to your production server.

We'll follow up with another article about deployment-specific configuration soon. If you want to learn more in the meantime you should head over to the official documentation.