|WikiProject Software / Computing|
|WikiProject Computer science|
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)
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 18.104.22.168 (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)
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 22.214.171.124 (talk • contribs)
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)
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?
- 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. 126.96.36.199 (talk) 18:47, 5 July 2008 (UTC)
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 188.8.131.52 (talk) 16:38, 27 February 2008 (UTC)
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.
- 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)
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
* 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
* 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, ...)
* 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.
* Code / application design to be tested automatically / packaged ... organized in sub part to avoid integration dependencies .....
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)
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.
- 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.
- The reason for Continuous Integration is the discovery that the cost to fix broken integration increases with the time between break & fix.
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
Maybe to be added?