Continuous Integration, was raised by Martin Fowler in 1999 . The fundamental CI feature is to fetch source code from code base timely(or by detecting code change), build automatically, inform the build result to development team.
Now, as a key software development practice, it’s wildly adopted by different projects, whatever it’s a Waterfall project or an Agile project.
There are many CI tools in the market, including open source and commercial. Which CI tool is best suited for you? You can find almost all the CI tools and the features from the CI Feature Matrix.
There is no one-size-fits-all solution. You can try one of the below tools, if you are new to CI.
Hudson is wildly used in GDC related projects – It’s easy to install and easy to use – from downloading to get it run, 30 minutes is enough. It has a bunch of plug-ins, SCM plug-ins, Build wrappers, reports and so on. You will find what you want from its plug-in list page.
Continuum is another recommendation which is also easy to install and easy to use. It’s an Apache software which is under very active development. It can handle Maven 2 as well as Maven 1, Ant and other scripts. Starting from release 1.3, Continuum supports ‘distributed builds’ and ‘parallel builds’ feature.
Thanks. Good to know another new one tool Continuum. One question, what is difference between ‘distributed builds’ and ‘parallel builds’?
Finding that Jira is popular used by those CI tools for issue tracking
For Mary’s question,I think ‘parallel builds’ means that the CI can run multiple jobs at the same time,and then there might have performance issue,then we need to distribute the jobs to one single CI server to others
Thanks Eric.
If search from Google with the key word “Continuous Integration”, you will find Martin Flower’s article (http://martinfowler.com/articles/continuousIntegration.html) comes out as the First result. I highly recommend to read this article.
Below practices are highlighted by Martin in the article:
* Maintain a Single Source Repository.
* Automate the Build
* Make Your Build Self-Testing
* Everyone Commits To the Mainline Every Day
* Every Commit Should Build the Mainline on an Integration Machine
* Keep the Build Fast
* Test in a Clone of the Production Environment
* Make it Easy for Anyone to Get the Latest Executable
* Everyone can see what’s happening
* Automate Deployment
I think ‘Keep the Build Fast’ is a major motivation for ‘Distributed builds’ and ‘Parallel builds’ features from Continuum.
For ‘Distributed builds’, Continuum used XML-RPC protocol to coordinate among a ‘Master’ and multiple ‘Build Agents’ to implement this feature.
And Continuum implement ‘Parallel builds’ feature, via configure multiple ‘Queues’ – just like different threads. The inter-dependent between queues are not supported.
For more detail information, please go to Continuum’s website.
Philip – this was a great post; especially with the reference to the feature matrix which I found very helpful given the number of CI tool names that seem to come up with customers.
Thanks!
Kevin
myself had been doing some looking around on this subject. Your website is about the best. my business demand you will keep writing.