You are currently offline, so some features of this site may not work fully.

Your browser doesn’t support some of the latest CSS features used to build this site.

Read more about my usage of new CSS features.

Building on my previous introductory post on getting set up with Travis CI, here’s a few more quick tips that I’ve learnt to optimise your build.
Note: these tips are based on my own experience building Node based projects.

Specifying Node version

You can adjust the Node version that your project uses to build by specifying the version number in your .travis.yml configuration file.

The virtual machine that Travis spins up then uses NVM to run your build on multiple versions. Using the keyword stable runs the latest safe version, which I find useful.

# .travis.yml
language: node_js
node_js:
  - 'stable'
  - '0.12'

Bear in mind that adding multiple versions will increase your time as the build process runs on all of them — but it’s nice to be able to specify which version in case you do need more than one environment.

Caching directories

One of the first things that automatically happens on your build server with a Node project is npm install to get dependencies from NPM.

We recently started caching the node_modules directory on the VM to speed up installation, and therefore the build.

An example of speeding up your build by caching directories.
The Travis build sped up after caching the node_modules directory.
# .travis.yml
cache:
  directories:
    — bower_components
    — node_modules
    — path/to/any/directory

A useful tip is to cache this directory and bower_components, or any other 3rd-party installed dependencies you have in your project.

Git checkout depth

Another optimisation is adjusting the git checkout depth in your config file. This means that the build server will check out only the latest commit(s) from your git repository.

I can’t think of a situation I’ve had yet that requires more than the very latest commit to build, so it’s worth doing this even if it only speeds up a little bit!

# .travis.yml
git:
depth: 1

Branch white/blacklist

Whitelisting the branches you want to build, or blacklisting the ones you don’t can be quite a useful feature.

I sometimes use blacklisting — the except parameter — to make sure that I’m not building every single test branch that I create. You can also use RegEx for this in your .travis.yml as shown below (eg: matching test-brand-update).

Using only allows you to do the inverse and whitelist branches, if you desire.

# .travis.yml
branches:
  except:
    — /^test-.*$/
  only:
    — master
    — develop

Post deploy tasks

I use NPM’s built-in hook post_deploy to run checks on my personal website after a deployment to AWS. This is very useful for me as one of the tasks performed checks for 404s using grunt-check-pages. Implementing this is as easy as adding your script/task name to .travis.yml as shown below:

# .travis.yml
after_deploy:
  — grunt post_deploy

TL;DR

To get started from scratch with a Travis continuous integration build, refer to my previous post entitled Travis ain’t scary — part of a mini-series in overcoming learning curves of new front-end tech.

This post was originally published on Medium.