Jenkins (https://jenkins-ci.org) seems to be the most popular tool for continuous integration. It is also one of the oldest open source projects in this field in pair with Hudson (the development of these two projects split and Jenkins is a fork of Hudson):
Jenkins is written in Java and was initially designed mainly for building projects written in the Java language. This means that for Java developers, it is a perfect CI system, but you may struggle a bit if you want to use it with another technology stack.
One big advantage of Jenkins is a very extensive list of features that Jenkins have implemented straight out-of-the-box. The most important one, from the Python programmer's point of view, is the ability to understand test results. Instead of giving only plain binary information about build success, Jenkins is able to present results of all tests that were executed during a run in the form of tables and graphs. This will, of course, not work automatically as you need to provide those results in a specific format at first (by default, Jenkins understands JUnit files) during your build. Fortunately, a lot of Python testing frameworks are able to export results in a machine-readable format.
The following is an example presentation of unit test results in Jenkins in its web UI:
The following screenshot illustrates how Jenkins presents additional build information, such as trends or downloadable artefacts:
Surprisingly, most of Jenkins' power does not come from its built-in features, but from a huge repository of free plugins. What is available from clean installation may be great for Java developers, but programmers using different technologies will need to spend a lot of time to make it suitable for their project. Even support for Git is provided by some plugin.
It is great that Jenkins is so easily extendable, but this also has some serious downsides. You will eventually depend on installed plugins to drive your continuous integration process, and these are developed independently from the Jenkins core. Most authors of popular plugins try to keep them up to date and compatible with the latest releases of Jenkins. Nevertheless, the extensions with smaller communities will be updated less frequently, and some day you may be either forced to resign from them or postpone the update of the core system. This may be a real problem when there is an urgent need for an update (a security fix, for instance), but some of the plugins that are critical for your CI process will not work with the new version.
The basic Jenkins installation that provides you with a master CI server is also capable of performing builds. This is different from other CI systems that put more emphasis on distribution and make strict separation from master and slave build servers. This is both good and bad. On the one hand, it allows you to set up a wholly working CI server in a few minutes. Jenkins, of course, supports deferring work to build slaves, so you can scale out in the future whenever it is needed. On the other hand, it is very common that Jenkins is underperforming because it is deployed in single server settings, and its users complain about performance because it is not providing enough resources. It is not hard to add new building nodes to the Jenkins cluster. It seems that this is a mental challenge rather than a technical problem for those that have got used to the single server setup.
In the next section, Buildbot is explained.