6 top continuous integration tools
Which tools are best when you’re looking to integrate code into a shared repository several times a day? Nitish Tiwari has the lowdown on the software you need to keep your continuous integration game strong.
Continuous integration (CI) is an integral part of an agile software development setup. Sprint after sprint, teams strive to “not break the build” while delivering incremental features. But when developers focus completely on adding features, code errors can sometimes creep in and render the software unusable.
To stop such errors from being integrated into the software configuration management (SCM), a CI server is the gatekeeper that helps keep a tab on code quality. Even if the code is integrated to SCM, a CI server can quickly tell you what went wrong. In this post, let’s take a look at six open source CI server tools that you can use in your agile setup.
Jenkins was created after a falling out between Hudson project contributors and the company that acquired Sun Microsystems. It is developed in Java and can be installed using simple
java -jar jenkins.war command after downloading the WAR file. You can also deploy it in servlet containers. Jenkins’ focus is on two major jobs: building/testing software projects continuously and monitoring externally run jobs. For the former, Jenkins supports an array of SCM tools—Git, Mercurial, Subversion, Clearcase, and many more. You can build Apache Ant and Apache Maven based projects and other shell scripts or Windows batch files for pre- and post-build activities. Note that almost all the configurations can be done via the web-based GUI.
Jenkins is available as a service from third-party vendors, but if you have a huge list of software releases to be tested it’s probably better to run it on your own servers—not only does this give complete control over infrastructure issues, but it’s also helpful for companies worried about software security.
Developed in Python, Buildbot is based on the Twisted framework. It started as an alternative to the Tinderbox project and is now used in Mozilla, Webkit, Chromium, and others. Buildbot installation has one or more masters and a collection of slaves. The masters monitor source code repositories for changes, coordinate the activities of the slaves, and report the results to users and developers. Slaves run on a variety of operating systems. You need to provide a Python configuration script to the master for the Buildbot configuration. This may be a little difficult for non-programmers to manage, but such scripts give Buildbot much-required flexibility.
The ideology behind this setup is that most of the CI tools come with fixed fundamental design and options limited to those envisioned by the authors of the tool. But use cases, such as mixed-language applications or complex release tasks, may cause those assumptions to be violated. Buildbot’s design allows your installation to grow with your requirements, beginning with simple processes and growing to meet your unique needs.
Travis CI is probably one of the easiest CI servers to get started with. Travis CI is open source and obviously free to host on your own server, but it also offers a SaaS version that allows free testing for open source projects. Setup is as easy as linking your GitHub account, giving the relevant permissions, and updating the travis.yaml file with your project specific requirements. A new Travis CI build is triggered after a file is committed to GitHub.
npm install strider. However, Strider is extremely customizable through plugins and may require you to put your hands in code—not a bad thing to do, but if you would like a quicker setup without much programming effort, you should probably look at other options.
Go was created and then open sourced by ThoughtWorks. As with other advanced CI servers, Go lets you distribute your builds across different systems and monitor them all in one place. To use this, you need to install it on your server—there is no SaaS available.
With Go, regularly performed tasks can be added as pipelines. The instances of these activities are called jobs. Another interesting addition is the ability to visualize the entire continuous delivery workflow with the value stream map. The map helps you track the entire change from commit to deployment.
Built on Ruby, Integrity needs Ruby 1.8.7 or newer, RubyGems 1.3.5 or newer, and Git 1.6 or newer. There’s no SaaS available and you need to install it locally before using it. The configuration is done using the “init.rb” file. A sample of this file is available on the project page. Another important thing to note is that Integrity currently works with Git only, so if you use another SCM tool this may not be right for you.
A version of this article was previously posted at Taiga Blog.