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.
# .travis.ymllanguage: node_js
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.
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.
On some projects we have found that this cuts the build time by more than half!
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!
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:
— grunt post_deploy
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.