There are many online CI services (such as Travis, CircleCI, Bamboo, and Shippable) as well as self-hosted CI-capable platforms (such as Jenkins, TeamCity, CruiseControl, and BuildBot). For CI, they pretty much have the same set of capabilities, and can perform the following tasks:

• Hook onto events and perform predefined tasks when triggered. For instance, when a new Git commit is pushed to the repository, the CI server would build the application and run the tests.
• Run tasks in a clean, standalone environment.
• Chain tasks together so that some tasks are triggered on the completion of the previous tasks. For instance, after the tests have finished, email the build and tests results to all developers.
• Store history of the builds and test results.

Since each CI platform is able to fulfill our requirements, our decision of which CI server to pick boils down to whether to use a hosted or self-hosted solution. As always, there're pros and cons to each approach:

• Costs: Most hosted CI services are free for open source projects but require a paid plan for private repositories. However, hosting your own CI server also incurs costs of running the server.
• Self-Reliance: Relying on external services for your workflow means if the external service is down, your workflow will be broken. However, most hosted CI services have very good uptime, so availability should not be a huge issue.
• Flexibility: With a self-hosted solution, you have complete control over the CI server, and can extend the code and feature set with plugins or packages. On the other hand, if you require a feature that is not supported in a hosted CI server, you'd have to raise a support ticket/feature request and hope it will get implemented.

In this chapter, we are going to demonstrate both the hosted and self-hosted solutions, using Travis and Jenkins, respectively. The majority of the chapter, however, will focus on Jenkins, as it is a much more powerful and generic automation server than Travis.