Talk:Continuous integration

From Wikipedia, the free encyclopedia

Contents 1 Spam 2 Missing Content 3 Comparative Chart Would Be Useful 4 Dedicated server 5 Expert needed 6 One size does not fit all

[edit] Spam

The Software section of this article is nothing more than a spamfest. I propose removing all non-notable entries (as determined by whether they have an article or not) and also all the redundant external links alongside the wikilinks. Objections? CiaranG 20:55, 30 January 2007 (UTC)

Done. CiaranG 23:08, 5 February 2007 (UTC)

[edit] Missing Content

This page equates Continuous Integration with just having a product running the build every so often. To my knowledge the phrase was coined by Martin Fowler and comprises as a way of setting out the build, automating the tests and other techniques he describes. There are also other related patterns and much that can be said about it's history: for example Tinderbox on the Mozilla project pre-dates the term by a couple of years and was already quite a rich CI environment--- although some of the techniques as described by Fowler are lacking--- it was used more as a tool to allow broader collaboration and checkin's from all over the world. —Preceding unsigned comment added by 195.212.199.56 (talk • contribs)

[edit] Comparative Chart Would Be Useful

Let's decide the columns for this chart. The first columns might be: System, Supported Platforms, Unit Testing Integration, IDE Integration, etc. —Preceding unsigned comment added by 199.67.203.141 (talk • contribs)

[edit] Dedicated server

In the "disadvantage list", there si "the need of a dedicated server for the builds". I don't think there is the need of a dedicated server.

Well, if the projects building are small, there might not be needed a dedicated server... but for big projects a fast multiprocessor server is recommended... Our build lasts almost 2 hours on a dedicated server P IV 3.2Ghz, 2 GB RAM.

I would contend that a build that takes two hours to run does not fit the definition of a Continuous Integration build. I firmly believe that the greatest benefits of establishing a Continuous Integration capability is to provide near-immediate feedback to the developers on the state of their software - does it build? does it integrate with other teams members' software? do the Unit and Integration tests pass? The key here is immediate or near-immediate feedback. I contend that the build, for continuous integration activity, should be kept to no more than 15 to 30 minutes. Even if this means cutting back on the number or types of tests being run. Developers have to feel confident in the CI environment and know that it will give them that feedback quickly. Even small teams can have dedicated servers. Technically, they don't have to be server-class machines at all. Even a, slightly, older desktop or laptop may suffice as a dedicated CI box. Larger organizations can even consider virtual machines running on mid-range servers - capable of hosting CI environments for multiple projects within the company. I suppose it depends on what is meant by dedicated. If you mean a machine that does nothing but host your CI environment - then I think this may not be necessary for all projects. My definition of a dedicated server is a machine that hosts my CI environment; is always on and polling my source code repository; is always ready to start a build; and can always provide feedback on the state of my build. HunterTech 13:16, 16 August 2007 (UTC)

[edit] Expert needed

This page needs the contibution of an expert. I've changed the format of the page making continuous integration refer to the practices that Fowler defines as continuous integration. I think it is a misconception to view Continuous Integration as the installation of a continuous integration server. Indeed Fowler acknowledges that CI is possible without a or any of the Software that is listed on the page. The article needs reworking to reflect the group of practices that are Continuous Integration certainly in XP.

Experts in the subject might be able to shed light on whether any other methodologies have been influenced by this and provide some history. It would be good to have some text which is less XP focused as clearly the practice has become more widespread. Also books on the subject elaborate some of these practices and update them. What happens for instance when decentralised source code management is used (like the linux kernel for instance)? Fowler's description does not fit or does it?

AndyGavin (talk) 22:25, 21 February 2008 (UTC)

[edit] One size does not fit all

I also agree that this pages needs some expert(s) to better organize the materials & feedbacks. In practice, the definition of CI means different things to different people. Martin's paper on this subject should be served as a declaration of common practices; better yet, a basis of agility metrics to measure the effectiveness of CI practices. The whole movement here is to mutate or correct current practices (a collective human behaviors) towards a better well-defined discipline. May be this is where the technology ends and the governance & policies begins. —Preceding unsigned comment added by 198.45.19.49 (talk) 16:38, 27 February 2008 (UTC)