This article cover how to use Travis CI service with NodeJS for an open source project hosted on GitHub. At the end, you would be able to setup a basic build pipeline to automatically validate your code using Continuous Integration (CI) .

And that’s all you need, thanks for the reading! Ah… ok, maybe there is needed something more…

Ok, for start building things with Travis you have to update your code. Once Travis detects some new branch or commits on your repo it will run a build with that code , but at this point, it will fail.

Setup Travis CI for NodeJS

Yes, there is a little thing to do before Travis starts working for us. It doesn’t know what to do with that GitHub repository, to help in this, the repo has to have a config file ( .travis.yml ) that tells Travis what to do with the code . If we don’t use this file it will try to build the project using Ruby.

.travis.yml

language: node_js
node_js: "node"

This is the simplest Travis CI config file for start building in NodeJS.

language : To set which engine are we using to build our project

node_js : To specify which version of node use for the build "node" === "latest version"

Note: Some logs traces have been omitted to improve readability. You can check the whole log in the Travis CI build report .

What has happened?

There are some good things and some bad thing to pay attention to. The first one is that Travis has made a build with node! It gives a lot of info about what is happening in that machine that is building the project in “the cloud” (OS version, node version, npm version, what things are installed in the system..)

Wait… This post for a file with 3 lines only?

Yep, but there was already some things done, like well-defined dependencies in the package.json and tests defined using node standard practices width npm test .

Want more? Ok, there is more to do.

Travis CI Caching

The Travis config file can define which folders should be cached to improve the builds time. In this case, I’m going to cache the node_modules folder to reduce the time installing dependencies and also for yarn .

THE Travis Status Badge

This is the only very thing why all of us integrate our projects with Travis. To be the fanciest on GitHub wearing a bunch of blue/green badges saying that everything is ok and all is up to date.

To get the code you have to click on the badge from the Travis CI page of your project, a dialog will appear showing you different options about which branch and in what kind of code you want the image, then add it wherever you want.

That image will show the updated build status of the branch you selected.

GitHub Code Supervision with Travis CI

Another cool thing Travis can do is to check every bit of code that changes in the project and avoid breaking changes to be merged into critical branches as well as notify about commits breaking the build.

Checking the commits history with Travis integrated there appears checks and crosses indicating if the build executed for that commit went ok, and by clicking them you can go to the Travis build logs.

To avoid direct commits against a branch in GitHub and instead add code to it by Pull Requests you can activate the Branch Protection under the Project Settings inside the Branches section. Once there select the branch you want to protect and check “Protect this branch”, “Require status checks to pass before merging”, “Require branches to be up to date before merging”, “continuous-integration/travis-ci” and “Include administrators”.

By this way, all the code to be modified in that branch has to pass through a PR and then complete a successful build with Travis.

Conclusion

Travis CI is perfect to ensure the sanity of your code and to maintain good practices against the project, it also helps to detect possible bugs caused by refactors or changes in the functionality of the project. But that’s not all, with advanced builds you could make deploys to production servers o build a compiled version for the end-user.