This article is rated B-class on Wikipedia's
content assessment scale. It is of interest to the following WikiProjects: | |||||||||||||||||||||||||||||||||||||||||
|
|
|
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)
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 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)
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)
Continuous Integration by definition means commit to trunk(mainline) daily (or more frequently). Any feature branches should merge with trunk daily. — Preceding unsigned comment added by 67.202.252.100 ( talk • contribs) 18:44, 24 April 2018 (UTC)
See also
alex ( talk) 11:20, 9 April 2013 (UTC)
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)
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)
What is the definition of the word "baseline" in the context of this article? — Preceding unsigned comment added by 71.62.123.140 ( talk) 13:34, 19 August 2015 (UTC)
Is there a list of CI software that can be linked? Interested in creation of a table in a separate article which can be linked? https://de.wikipedia.org/wiki/Kontinuierliche_Integration#Software is a good start. -- Zgh ( talk) 12:41, 27 April 2015 (UTC)
The costs and benefits section of the article only discusses the topic about its advantages, but none disadvantages (if there are any). At very least, the section could be copywritten into a more encyclopedic tone. Note the lack of citations in the section. 80.222.34.157 ( talk) 05:47, 2 May 2016 (UTC)
@ Walter Görlitz: I see you reverted my Bold change, as you have every right to do under WP:BRD, arguing that CI is not a version control strategy but an agile practice. The two are not contradictory and CI is in fact first and foremost a version control strategy, though the term is often misapplied to having a build server that runs all sorts of automated tests. Martijn Meijering ( talk) 21:26, 8 April 2017 (UTC)
The sentence "The longer a branch of code remains checked out, the greater the risk of multiple integration conflicts [...]" is ambiguous and seem wrong to me however I try to interpret it. I guess one of the following is meant:
But both are somewhat the opposite of the sentence as is - 1) due to the "not", 2) due to "check-in" instead of "check-out".
And while as stated "Not checking out" (at all) would solve integration problems - which is somewhat true because no development would take place and thus no conflicts would emerge, that's hardly meant. :D Florian Finke ( talk) 09:17, 26 August 2019 (UTC)
So is how Wikipedia (the text, not the underlying Wikimedia software) created a version of continuous integration? Yes, no, maybe? (Or maybe Wikipedia could benefit from CI?) -- llywrch ( talk) 21:12, 5 December 2019 (UTC)
I renamed workflows to 'related practices'. It's a rather long list of stuff that seems to be associated with CI, but not central to it. IDK if any of it belongs in this article. Maybe it's see also info. Stevebroshar ( talk) 23:39, 7 May 2024 (UTC)
This article is rated B-class on Wikipedia's
content assessment scale. It is of interest to the following WikiProjects: | |||||||||||||||||||||||||||||||||||||||||
|
|
|
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)
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 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)
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)
Continuous Integration by definition means commit to trunk(mainline) daily (or more frequently). Any feature branches should merge with trunk daily. — Preceding unsigned comment added by 67.202.252.100 ( talk • contribs) 18:44, 24 April 2018 (UTC)
See also
alex ( talk) 11:20, 9 April 2013 (UTC)
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)
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)
What is the definition of the word "baseline" in the context of this article? — Preceding unsigned comment added by 71.62.123.140 ( talk) 13:34, 19 August 2015 (UTC)
Is there a list of CI software that can be linked? Interested in creation of a table in a separate article which can be linked? https://de.wikipedia.org/wiki/Kontinuierliche_Integration#Software is a good start. -- Zgh ( talk) 12:41, 27 April 2015 (UTC)
The costs and benefits section of the article only discusses the topic about its advantages, but none disadvantages (if there are any). At very least, the section could be copywritten into a more encyclopedic tone. Note the lack of citations in the section. 80.222.34.157 ( talk) 05:47, 2 May 2016 (UTC)
@ Walter Görlitz: I see you reverted my Bold change, as you have every right to do under WP:BRD, arguing that CI is not a version control strategy but an agile practice. The two are not contradictory and CI is in fact first and foremost a version control strategy, though the term is often misapplied to having a build server that runs all sorts of automated tests. Martijn Meijering ( talk) 21:26, 8 April 2017 (UTC)
The sentence "The longer a branch of code remains checked out, the greater the risk of multiple integration conflicts [...]" is ambiguous and seem wrong to me however I try to interpret it. I guess one of the following is meant:
But both are somewhat the opposite of the sentence as is - 1) due to the "not", 2) due to "check-in" instead of "check-out".
And while as stated "Not checking out" (at all) would solve integration problems - which is somewhat true because no development would take place and thus no conflicts would emerge, that's hardly meant. :D Florian Finke ( talk) 09:17, 26 August 2019 (UTC)
So is how Wikipedia (the text, not the underlying Wikimedia software) created a version of continuous integration? Yes, no, maybe? (Or maybe Wikipedia could benefit from CI?) -- llywrch ( talk) 21:12, 5 December 2019 (UTC)
I renamed workflows to 'related practices'. It's a rather long list of stuff that seems to be associated with CI, but not central to it. IDK if any of it belongs in this article. Maybe it's see also info. Stevebroshar ( talk) 23:39, 7 May 2024 (UTC)