Further Travis tips

Dan Furze
Dan Furze
Feb 1, 2016 · 3 min read

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.

These tips are based on my own experience building Node based projects.

Specifying Node version

Specifying the latest version can be useful

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.

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

Cache your dependencies to speed up installation

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.

Image for post
Image for post
An example of speeding up your build by caching directories

On some projects we have found that this cuts the build time by more than half!

Image for post
Image for post
The Travis build sped up after caching the node_modules 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

No need for more than the latest commit

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!

Branch white/blacklist

Travis allows you to white/blacklist branches, if you so desire

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.

Post deploy tasks

Use the post_deploy task to run checks after your projects has finished deploying

I use the 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:

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.

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch

Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore

Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store