Talk:Continuous integration/Archive 1

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)[reply]

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

Cleaned again -- removed anything from notable software that isn't a link to a wikipedia article. 12.47.51.69 (talk) 21:02, 25 August 2008 (UTC)[reply]

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)

I don't think Fowler coined the term, it dates back to the early days of XP, 1997 or earlier. Martijn Meijering (talk) 10:09, 9 September 2011 (UTC)[reply]

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)

Comparison matrix created, feel free to fill in more (Kslotte (talk) 18:37, 22 May 2009 (UTC))[reply]

Dedicated server

In the "disadvantage list", there is "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)[reply]

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)[reply]

Other than experienced and appropriately knowledgeable software or industrial methods engineers or academics there is no one that can reasonably be expected to function as an expert for this particular branded methodology. Am familiar with it's general product line (i.e. Agile, et. al.) and will review shortly. 74.78.162.229 (talk) 18:47, 5 July 2008 (UTC)[reply]

Flip-flop: I find this trivial/vacuous so I won't be giving further attention. 74.78.162.229 (talk) 22:31, 5 July 2008 (UTC)[reply]

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)[reply]

History does not start with XP

Continuous integration has a longer history than this article indicates. Integration has been performed on software projects for a long time. A number of the elements that are now seen as continuous integration were described by Booch.

In the context of continuously integrating a system's architecture, establish a projects rhythm by driving to closure certain artifacts at regular intervals

He then goes on to say there are three parts to this:

First, the macro process of object-oriented development is one of "continuous integration.". Rather than set aside a period of formal testing at the end of the life-cycle, the object-orientated life cycle tends to integrate the parts of software (and possibly hardware) at more regular intervals...

Second, at regular intervals, the process of continuous integration yields executable releases that grow in functionality each release...

His final part is that by having integration more frequently quality can be assessed by management, risks can be identified and acted-upon early.

AndyGavin (talk) 13:55, 18 August 2008 (UTC)[reply]

This is good information that we can try to work into the article. But it's not CI in the sense that that term was used in XP. There CI means checking in several times a day or more, not once every iteration. Martijn Meijering (talk) 10:12, 9 September 2011 (UTC)[reply]