April 13, 2016
Losing time with deploying your ‘small’ projects manually? In 30 minutes you setup an automatic deploy process with this tutorial.
The prerequisites for this tutorial are:
Follow the steps below, and you are up in no time:
Travis CI is like a kitchen robot: he does all boring, repetitive but - Ooh soO - important work without you even have to bother!
We will first start with the most basic automatic deployment. You don’t need Travis and other fancy tools to deploy automatically. With only Github and Heroku, an automatic deployment can be realised.
Tip: Don’t forget, you are using a public github repository for deployment to your environment: use the Heroku Config Variables for passwords and other secret stuff. Add a Procfile to Heroku.
Ok, now that we have a simple and basic automatic release, we will take it one step further.
Why adding Travis CI to this process? Well, as we want to make sure that are project is always in a healthy and deployable state, we will add Travis as a sort of gatekeeper. Travis will perform all needed pre- and post processing that you want, all by declaring them in a simple file.
If interested, a working example can be found here
This part is specific for Node.js applications
We added Travis to the build process, but we didn’t really use it’s power yet. This section will show a part of it’s power by adding a test battery to the automatic deployment process. We don’t want to deploy our application without decent testing taking place!
If your application doesn’t yet contain any tests, first add some tests! We are using Mocha and Chai. Add a test script to your package.json which triggers your testing battery. If you are used to add a -w flag to mocha (which watches automatically for changes), add a specific script for travis without the -w. Otherwise your travis build will hang forever.. In my case I just added a ‘test-single’ script which does simply this: ‘NODE_ENV=test mocha’. Then I add a script to my Travis.yml: ‘npm run test-single’. Once this is done, commit your changes and check if travis is successfully running your tests.
Make sure to enable the flag in the Heroku deployment section ‘Wait for CI to pass before deploy’.
Sweet! Now Travis is automatically performing our tests, and only when those are successful, the deployment to heroku is taking place. Now that we have the automatic testing battery, it would be nice to have some reporting about our code coverage. That’s where Istanbul.js and Codecov come in to play.
Istanbul.js is a node module which states itself as - quoting -‘Yet another JS code coverage tool that computes statement, line, function and branch coverage with module loader hooks to transparently add coverage when running tests.’
YES, that’s exactly what we need! Adding it is simple:
Running your tests should now reveal the test coverage at the end of your tests. Also istanbul will have created a coverage directory in your project home directory in which you can find an lcov-report with an index.html. Opening this file in your browser should reveal a detailed overview of your test coverage. Et voila!
Istanbul can also be used to verify if the coverage meets the project standards. Only if the standards are met, the project can get deployed. Implementing this is as simple as this:
Travis will now only deploy when the project testing standards are met!
Tip: add the coverage folder to your .gitignore file, it doesn’t make sense to push this folder to your remote git repository.
Now that we have our test coverage, it would be nice to have this report somewhere easily accessible. That’s where codecov comes in.
Travis will now trigger an upload of the testing results to codecov. This will be done after a successful test battery and before deployment.
Et voila, this article showed you the power of Travis: The build and deployment process can be completely and easily customised with small subtasks, which are easily added as hooks to the travis.yml file. Use the following as an example project for more info, or add questions/comments/remarks below.
Written by Jonathan Dierckens who lives and works in Ghent, trying to build useful things.