Overall Satisfaction with Travis CI
I use the open source installation of Travis CI (https://travis-ci.org/jawnsy) for public GitHub projects. It's the de-facto continuous integration tool for public GitHub repositories, as it's free and works pretty well. It's used by a number of organizations that I'm a member of, including Kubernetes (https://github.com/kubernetes/kubernetes) and OpenShift (https://github.com/openshift/origin), though many larger projects also use Jenkins to provide a more customizable build environment. This can be useful for things like building Amazon Web Services AMIs, integration with external services that Travis doesn't support, etc.
- It's simple and easy to get started (it can detect the language being used based on build configuration files like a Maven pom.xml).
- It's free (as in beer) for open source projects.
- It has a responsive staff (you can file issues on GitHub to ask for new languages or packages to be supported, and the turnaround time isn't too bad for the free offering).
- The user interface is beautiful and easy-to-use, including features like live-tailing in-progress builds.
- It supports specifying private environment variables and encrypted credentials, so that you can safely automate deployments (for example, pushing built docker images to DockerHub).
- It only supports Linux and OS X, so other vendors (like AppVeyor) have to be used for Windows support.
- The build matrices can be difficult to set up in the travis.yaml file.
- Build queues can be long sometimes, since the open source offering has limited infrastructure. This problem does not affect the commercial offering, however.
- Builds are limited to various versions of OS X and Ubuntu; other operating systems can be used for teh build via the Docker support.
- It's improved my ability to deliver working code, increasing my development velocity.
- It increases confidence that your own work (and those of external contributors) does not have any obvious bugs, provided you have sufficient test coverage.
- It helps to ensure consistent standards across a team (you can integrate process elements like "go lint" and other style checks as part of your build).
- It's zero-cost for public/open source projects, so the only investment is a few minutes setting up a build configuration file (hence the return is very high).
- The .travis.yml file is a great way for onboarding new developers, since it shows how to bootstrap a build environment and run a build "from scratch".
There are a number of alternatives to Travis CI, but Travis remains the most popular, since it was one of the first to show up. It has a lot of examples, support for building dozens of languages, and good documentation. Significant portions of the system are open source, so you can examine how builds are run (and optionally to suggest changes). It has great integration with GitHub. If you don't need Windows support, then Travis is probably the best option available today.
If you have an open source project on GitHub, Travis is the best option available, and it's in widespread use. There are many examples of usage in open source projects of varying complexity, so it's simple to copy bits and pieces from those. The Travis Build Status badges are beautiful and easy to add. The user interface is great if you need to manually retry builds or check logs. It automatically builds all pull requests in a secure way, so that you can check contributions without paying for your own build infrastructure, and without having to configure/manage it.