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.
 

Actionable suggestions from talk archives[edit]

  • History before Extreme Programming
  • What other methodologies have been influenced by CI?
  • 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?

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)

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

Agreed, done. -- Beland (talk) 16:42, 25 August 2014 (UTC)

Trunk based development[edit]

Maybe to be added?

See also

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

Section Software is just a list[edit]

Why is the section Software just a list of some CI software? That makes no sense because it already exists the comparison list. TeamBuild2020 (talk) 08:29, 18 August 2014 (UTC)

It's also unfortunate that people call this Continuous Integration software, when it really is software for Continuous Integration Testing, which is not the same thing. Martijn Meijering (talk) 11:12, 18 August 2014 (UTC)
If there are no objections, I will delete the software section, since it, like many other lists on Wikipedia, has become just a place for (internal) link spam. Michaelmalak (talk) 12:52, 18 August 2014 (UTC)
Thanks! TeamBuild2020 (talk) 16:33, 20 August 2014 (UTC)
Some of the software listed here wasn't there; I noted these at Talk:Comparison_of_continuous_integration_software#Missing if anyone cares to integrate them into the charts in that comparison article. -- Beland (talk) 17:13, 25 August 2014 (UTC)

Definition[edit]

The definition of CI in this article needs to be improved. Unfortunately there is a lot of confusion about the meaning of the term in the industry. It means two things:

1. Integrate code streams to trunk several times a day, ideally by always committing to trunk rather than to a separate branch. 2. Make sure the code is always in a workable state and develop functionality in vertical slices / walking skeletons rather than layer by layer or component by component.

It does not include 3. having an automated build server and using automated integration testing, though that is a very useful complementary practice. Unfortunately when people say CI, they often mean precisely this complementary practice rather than the two defining activities. The list of software in the article really deals with 3., while 2. isn't mentioned much if at all. Martijn Meijering (talk) 11:29, 18 August 2014 (UTC)