Travis CI (https://travis-ci.org/) is a continuous integration system sold in Software as a Service form. It is a paid service for enterprises, but can be used for free in open source projects hosted on GitHub:
Naturally, it is the free part of its pricing plan that made it very popular. Currently, it is one of the most popular CI solutions for projects hosted on GitHub. But the biggest advantage over older projects, such as Buildbot or Jenkins, is how the build configuration is stored. All build definition is provided in a single .travis.yml file in the root of the project repository. Travis works only with GitHub, so if you have enabled such integration, your project will be tested on every commit if there is only a .travis.yml file.
Having the whole CI configuration for a project in its code repository is really a great approach. This makes the whole process a lot clearer for the developers and also allows for more flexibility. In systems where build configuration must be provided to build a server separately (using a web interface or through server configuration), there is always some additional friction when something new needs to be added to the testing rig. In some organizations where only selected staff are authorized to maintain the CI system, this really slows the process of adding new build steps down. Also, sometimes, there is a need to test different branches of the code with completely different procedures. When build configuration is available in project sources, it is a lot easier to do so.
The other great feature of Travis is the emphasis it puts on running builds in clean environments. Every build is executed in a completely fresh virtual machine, so there is no risk of some persisted state that would affect build results. Travis uses a rather big virtual machine image, so you have a lot of open source software and programming environments available without the need for additional installs. In this isolated environment, you have full administrative rights, so you can download and install anything you need to perform your build, and the syntax of the .travis.yml file makes this very easy. Unfortunately, you do not have a lot of choice of the operating system available as the base of your testing environment. Travis does not allow you to provide your own virtual machine images, so you must rely on the very limited options provided. Usually, there is no choice at all and all the builds must be done in some version of Ubuntu, macOS, or Windows (still experimental at the time of writing this book). Sometimes, there is an option to select some legacy version of one system or the preview of the new testing environment, but such a possibility is always temporary. There is always a way to bypass this. You can run another virtual machine or container inside of the one provided by Travis. This should be something that allows you to easily encode VM configuration in your project sources, such as Vagrant or Docker. But this will add more time to your builds, so it is not the best approach you could take. Stacking virtual machines this way may not be the best and most efficient approach if you need to perform tests under different operating systems. If this is an important feature for you, then this is a sign that Travis is not a service for you.
The biggest downside of Travis is that it is completely locked to GitHub. If you would like to use it in your open source project, then this is not a big deal. For enterprises and closed source projects, this is mostly an unsolvable issue.
In the next section, GitLab CI is explained.