Cloud-based Continuous Integration Projects Prove the Concept

Datetime:2016-08-23 02:33:51          Topic: Continuous Integration           Share

"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 BambooCruiseControl , and  JetBrains TeamCity . (An extensive list of continuous-integration products is available on  Wikipedia .) Among the cloud versions of popular IDEs are  Cloud9Compilr , and  Nitrous . The hosted-CI services  CodeshipSemaphor , 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.





About List