|WikiProject Software / Computing|
|WikiProject Computer science|
Actionable suggestions from talk archives
- 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?
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?
Section Software is just a list
- 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)
- Thanks! TeamBuild2020 (talk) 16:33, 20 August 2014 (UTC)
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)