Talk:Continuous integration

message: * 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?
:These are actionable? Stevebroshar (talk) 23:35, 7 May 2024 (UTC)
thread_title: Actionable suggestions from talk archives

message: 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)
replies: text: Um. what? Stevebroshar (talk) 23:36, 7 May 2024 (UTC)
thread_title:  Global comments 

message: 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)
replies: text: 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)
thread_title:  "Opposing theory" 

message: 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)
replies: text: Agreed, done. -- Beland (talk) 16:42, 25 August 2014 (UTC)
thread_title:  Rename Advantages/Disadvantages 

message: 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)
replies: text: The requirement of committing to trunk daily is already stated in the article. We can certainly reference Trunk-based development, it is basically a new name introduced for CI after people started redefining the latter to mean having a build server that watches a repo and runs a set of tests and other static analysis against it. Not everybody agrees with this change of terminology though, Martin Fowler for instance is a prominent opponent. Martijn Meijering (talk) 16:51, 25 April 2018 (UTC)
thread_title:  Trunk based development 

message: 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)
replies: text: 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)

text: 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)
replies: text:  Thanks! TeamBuild2020 (talk) 16:33, 20 August 2014 (UTC)
replies: text: 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)
thread_title:  Section Software is just a list 

message: 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)
replies: text: The word integration means to co-locate stuff (#1). But, I agree that CI generally includes #2, make sure the code is always in a workable state. In order to implement #2 people often setup a build server to compile, run unit tests .... So, there is a level of abstraction there. #2 is the goal and #3 (automated build server) is a common implementation. Stevebroshar (talk) 23:08, 7 May 2024 (UTC)

text: It can mean other things, but for CI it usually means the tip/head of a branch. Stevebroshar (talk) 23:10, 7 May 2024 (UTC)
thread_title:  Definition 

message: 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)
replies: text: There used to be a list, but it was deleted. I'm not a fan of adding it back, because it was actually a list of continuous integration testing / automated build software, which though useful, is not the same thing. CI itself requires little more than version control software and a testing framework. Martijn Meijering (talk) 13:30, 27 April 2015 (UTC)
replies: text: That's useful feedback, thank you. The question left unanswered is whether it can be moved to an external article and enhanced and cleared (to contain CI software only) there. I agree that restoring in the article is a bad idea. -- Zgh (talk) 13:40, 27 April 2015 (UTC)

text: In general, I finds WP lists to be low value. Stevebroshar (talk) 23:11, 7 May 2024 (UTC)
thread_title:  List of CI software 

message: 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)
replies: text: Today, there is a costs section which covers downsides/disadvantages. I guess someone added that at some point in the last 8 years. Stevebroshar (talk) 11:26, 1 June 2024 (UTC)
thread_title:  No mention of disadvantages of continuous integration 

message: 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:
# "The longer a working copy is not updated ..." by checking out the main branch again (and - if present - merge conflicts) - so rather NOT checking out frequently results in the problem
# "The longer a branch is not committed ..." So not checking in results in the problem - rather than having checked out
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)
replies: text: Your comments seem reasonable. :WP:SOFIXIT. Walter Görlitz (talk) 14:28, 26 August 2019 (UTC)

text: That was in a section called 'rationale', but there was nothing rationale about it. It's just a statement of the way things go. Describes a risk. ... thing is CI doesn't help with it. ... anyway, I moved that info to a section called related practices which is kind of a punt on whether any of that info is worthwhile Stevebroshar (talk) 23:15, 7 May 2024 (UTC)
thread_title:  Misleading phrase 

message: 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)
replies: text: You are talking about how WP article content is updated? If so, then the answer is no. That's a database update. CI is about building an application from source code. Very different.Stevebroshar (talk) 09:54, 7 May 2024 (UTC)
thread_title:  Trying to understand this concept 

message: 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)
thread_title:  Related practices