Talk:Continuous integration

From Wikipedia, the free encyclopedia
Jump to: navigation, search
WikiProject Software / Computing   
WikiProject icon This article is within the scope of WikiProject Software, a collaborative effort to improve the coverage of software on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.
 ???  This article has not yet received a rating on the project's quality scale.
 ???  This article has not yet received a rating on the project's importance scale.
Taskforce icon
This article is supported by WikiProject Computing.
 
WikiProject Computer science  
WikiProject icon This article is within the scope of WikiProject Computer science, a collaborative effort to improve the coverage of Computer science related articles on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.
 ???  This article has not yet received a rating on the project's quality scale.
 ???  This article has not yet received a rating on the project's importance scale.
 

Spam[edit]

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)
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)

Missing Content[edit]

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 (talkcontribs)

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)

Comparative Chart Would Be Useful[edit]

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 (talkcontribs)

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

Dedicated server[edit]

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)

Expert needed[edit]

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)

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)
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)

One size does not fit all[edit]

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)

History does not start with XP[edit]

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)

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)

Global comments[edit]

I'm agree with most of the comments, and the presentation is too much linked to Agility practices. CI is independent (even if it's strengthen agility implementation).

My comments on the page are : The points instead of being just a bullet list may be structured : Revision Control :

  * maintain a code respository
  * commit frequency
  * Every commit should be built

BUILD

  * Manage : dependencies / compilation / packaging
  * May include : tests (not yet distinction among UT/ Fonctional test), SCA (static code analysis)
  * keep it fast and simple
  * may be different for each library of a project, ... but try to keep it common
                   

Tests :

  * for each libraries run Unit tests, and you should have a coverage > 90% elsewhere it's useless.
    (you don't benefit fully of having UT in place)
  * Functional test for applications , and this can be an open door to virtualization, test world (selenium, ...)
 

Scalability :

   * CI is scalable, especially new CI tools as they provide remote build mechanism 
   * CI is just the glue among your build, and a tools that keep history (build, SCA metrics, UT trend, ...)
   * The complexity of the CI comes from your build / test process, nothing link directly to CI.
   

Requirement :

    * Code / application design to be tested automatically / packaged ... organized in sub part to avoid integration dependencies .....


I've got also some little comments in each section .... Laurent Tardif (talk) 09:13, 21 November 2008 (UTC)

"Opposing theory"[edit]

The article mentions the "opposing theory" of "Before submitting work, each programmer must do a complete build and test. All programmers should start the day by updating the project from the repository. That way, they will all stay up-to-date." Surely this is fully in line with the philosophy, not opposed to it? Jpatokal (talk) 04:41, 21 November 2011 (UTC)

The formulation is awkward, but I think what is meant it that there are variants of CI and that one variant requires developers to run all tests on their local copy before committing, instead of depending on an automated build on the build server. To be honest, I think running at least all *unit* tests locally before committing is part of the definition of CI. Martijn Meijering (talk) 15:17, 21 November 2011 (UTC)

Lede[edit]

The lede focuses on CI as part of quality control, but that's not its main focus. As the name suggests it's mainly an integration practice. It does have a relationship with quality control, running and passing all unit tests before integration is good for quality too, and a CI server is a good place to run all sorts of static and dynamic analysis tools, which is also good for quality control. But the main reason for CI is not quality control, but easier integration. Martijn Meijering (talk) 15:43, 19 April 2012 (UTC)

If CI wasn't being done for quality control, then we wouldn't need to do it continuously and could merely do it on demand - as it used to be done, two decades ago.
If you didn't integrate continuously it wouldn't be CI by definition. Quality control doesn't enter into that. Martijn Meijering (talk) 16:45, 19 April 2012 (UTC)
The reason for Continuous Integration is the discovery that the cost to fix broken integration increases with the time between break & fix. If integration breaks (and it will), then it's worth making an investment to detect this early by running trial integrations continuously. Andy Dingley (talk) 16:16, 19 April 2012 (UTC)
CI is not about trial integrations, but about real integration. Yes, it becomes harder the longer you put it off, hence the idea of continuous integration. Again, we don't do it because we have too many bugs, but because we don't want integration problems. Primarily it solves a different problem than low quality: if you work in parallel each of the branches may still be of high quality, but merging them can be extremely difficult.
Too many people confuse having a CI server like Jenkins or Cruise Control with doing CI. You can have a server and use parallel branches and only integrate once a week. The server would still be useful, but it wouldn't be continuous integration. Martijn Meijering (talk)
The reason for Continuous Integration is the discovery that the cost to fix broken integration increases with the time between break & fix.
That's the reason for having a build server, not for CI itself. The reason for that is the discovery that the longer between *branching* and *merging* (not breaking and fixing the build) the more difficult it is. Martijn Meijering (talk) 16:49, 19 April 2012 (UTC)

Remame Advantages/Disadvantages[edit]

Hi, I think the titles "Advantages" and "Disadvantages" are misleading considering the lists they caption. The list of Disadvantages aren't really disadvantages inherent to the methodology, they are rather costs of implementing it. They are not disadvantages that apply specifically to this methodology. Therefore I propose that the sections be named "Benefits" and "Costs" instead of "Advantages" and "Disadvantages". AadaamS (talk) 14:23, 5 March 2013 (UTC)

Trunk based development[edit]

Maybe to be added?

See also

alex (talk) 11:20, 9 April 2013 (UTC)