"Continuous integration" is one of those things that sound like a good idea, until you try them. In the real world, you never have a "perfect" version of an application out in the field. Fortunately, the "good enough" programs created using cloud-based continuous-integration services come together quicker and simpler than their offline counterparts.
The pre-eminent CI server is Jenkins ; as Tech Republic's Nick Hardiman writes in a February 3, 2015, article , alternatives include Atlassian Bamboo , CruiseControl , and JetBrains TeamCity . (An extensive list of continuous-integration products is available on Wikipedia .) Among the cloud versions of popular IDEs are Cloud9 , Compilr , and Nitrous . The hosted-CI services Codeship , Semaphor , and Travis can read from GitHub and write to Heroku.
In a January 5, 2015, post , Yegor Bugayenko updates his thorough comparison of 13 cloud CI services, which he originally posted in October 2014. Bugayenko's top four services are Travis ($129 per month), Appveyor ($39 per month), Wercker (free), and Shippable ($1 a month). Appveyor is the only one of the 13 to run Windows builds. Bugayenko notes that although Java and Ruby are considered platform independent, builds that run on Linux often don't pass on Windows or Macs.
The 13 hosted CI services run primarily on Linux and cost from nothing to $129 per month. Source: Yegor Bugayenko
Large Development Projects Put CI Services to the Test
One of the largest open source projects is OpenStack . The developer community supporting OpenStack has created a system for code review, testing, and continuous integration. Among the infrastructure's components are unit tests, functional tests, integration tests, a patch review system, and automatic builds. Adalberto Medeiros describes the project in a September 23, 2014, post on IBM's ThoughtsOnCloud.
The OpenStack CI environment relies on such tools as DevStack, Grenade, and Tempest to automate the process. The Gerrit build and patch review system works with these tools to verify every proposed change to the project.
The OpenStack CI process integrates diverse components to verify changes before they are added to OpenStack projects. Source: IBM ThoughtsOnCloud
Gerrit uses Zuul to check all patches for dependencies, and to merge the changes once they pass. The Jenkins build automation system handles the changes as jobs, Nodepool creates the images and VMs to run the jobs, and the Jenkins Job builder automates the creation of the jobs required to test the environment. (Miguel Zuniga's presentation Continuous Integration and Deployment Using OpenStack can be viewed on the OpenStack site.)
The reality for a great number CI projects is that developers ignore the build status warnings, as Bugayenko explains in an October 29, 2014 post entitled Continuous Integration Is Dead . This is a follow-up to the September 26, 2014 post entitled Why Continuous Integration Doesn't Work .
Bugayenko's proposed solution is to create a read-only master branch that prohibits anything from being merged into the master. When anyone proposes a change, a script is created that will merge, test, and commit. Any branch that breaks a unit test causes the entire branch to be rejected. Bugayenko claims that such a system makes coders immediately responsible for the code they write.