5 Great Reasons to Use Travis-CI

I use the service of Travis-CI now for a year. In that time the continuous integration has often pointed out problems I never had on my machine and let me quickly fix them, while I still know what the last change was about. If you don’t already use a service like Travis-CI you definitely should go and activate it. Here are 5 points on why this is a good decision.

 

Easy Set-up

The initial configuration of Travis-CI was done in a few minutes. Getting an account, hocking-up the Git repository and adding a .travis.yml file was easy and straight forward. Doing that in Ruby or in Java required only a quick read of the documentation and all was ready to go. More special settings like allowed failures are easy to implement as well, even when you don’t need them at first.

 

Always there

As soon as Travis-CI is up and running you don’t have to think about it. When you commit a change then a build will be triggered automatically and as long as everything works as expected, you will hear nothing. You don’t have to start another machine or do some manual work – all is cared for and just works.

 

A Safety Net

The big benefit of continuous integration comes when something stops working. At that point you get an email that informs you about the problem and you can act. The faster you push your commits, the faster you will get feedback. Most of the time that will be so fast that you still can remember what your last change was all about. Without having to figure out your code you can fix the problem faster.
The same is true for missing files: If you forget to commit a file the build succeeds on your machine, while the build server catches that error and sends you a reminder.

 

Better Tests

When your test suite runs with every build you quickly find out which tests are reliable and which are not. With that you can act quickly and improve your tests, long before you stop trusting them for all their false alarms. With not much additional effort you soon know what works and which parts you better test using a different approach.

 

Uncovered Environmental Problems

As soon as your development environment works you stop updating it. Every change could break it and you will end up with projects that only can be built on one machine. Having a build server that always creates the whole environment from scratch prevents you from ending in such an environment. As soon as something no longer can be installed or configured you get an alarm. Don’t ignore those problems and fix them – that will prevent simple problems from turning into big ones.
(Your .travis.yaml file will soon be an up-to-date instruction for setting up your environment, which is another benefit you get for free.)

 

Conclusion

Travis-CI saved me hours in the last year with an early alarm for every problem one of my projects had. With such a simple set-up you will not have to wait long until Travis-CI saves you time as well. If you use it in an Open Source project you get all the benefits for free.

Leave a Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.