Talk:Continuous integration

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?

Global comments

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"

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

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

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

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

• http://paulhammant.com/2013/04/05/what-is-trunk-based-development/
• http://petermorlion.blogspot.fr/2011/10/trunk-based-development.html

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

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)

Section Software is just a list

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

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)

List of CI software

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)

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)

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)

No mention of disadvantages of continuous integration

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)

CI is a version control strategy

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

I see you when stated it was a revision control strategy and it's not. It is not used to do revision or version control. With a WP:RS to support your claim I won't even take it on faith. Walter Görlitz (talk) 21:45, 8 April 2017 (UTC)

Why do you say it's not a version control strategy? Feature branches are one well-known way of using your version control system, CI is another (some call it trunk-based development). What's wrong with calling that a version control strategy? Martijn Meijering (talk) 22:00, 8 April 2017 (UTC)

Because it's not. Feature branches are a revision control feature, but just because a company or team only deploys off its master branch and do so regularly doesn't mean it's a version control strategy. A version control strategy is whether to use feature branches for development or not. A version control strategy is what approach to merging to master is used (merge master to branch then back to master or merge feature branch directly to master). A version control strategy is whether a feature branch is close, or deleted or not. CI is not a version control strategy in any sense of the term. Walter Görlitz (talk) 22:08, 8 April 2017 (UTC)

I don't understand. You say that whether to use feature branches or not is a version control strategy. But that's exactly what CI is, CI means not using feature branches. Or at least, that's a large part of what CI is. Do you disagree with that? A bit earlier you refer to deploying from master only or not. Is that part of your definition of CI? Martijn Meijering (talk) 22:16, 8 April 2017 (UTC)

That's one way it is run. In some cases, a feature may take longer to develop and so a feature branch is required. 03:52, 9 April 2017 (UTC)

How much longer would you say? Note that a feature could easily take several days (or even weeks!) and still not require feature branches. [User:Mmeijeri|Martijn Meijering]] (talk) 10:07, 9 April 2017 (UTC)

Agreed that one developer could work on a a feature for several years and not require a feature branch, but that is unlikely to work when you have a team. Walter Görlitz (talk) 04:53, 10 April 2017 (UTC)

This could work just fine with a team too. A person could easily commit from his working copy indefinitely. I have a feeling the root of the problem here is the semantic diffusion Fowler talks about. It would be helpful if we could clarify the exact definitions the three of us are working form. If you look at the points 1-3 below, which ones are part of your definition of CI? Is there anything you feel shouldn't be in there or anything you feel is missing? Martijn Meijering (talk) 14:55, 10 April 2017 (UTC)

It could work, but generally doesn't. I'm not reading your essay below. Cheers. Walter Görlitz (talk) 15:24, 10 April 2017 (UTC)

Care to explain the seeming hostility? Martijn Meijering (talk) 15:35, 10 April 2017 (UTC)

• Obviously it's not a version control strategy. It doesn't depend on the existence of version control. You could (and this would be foolish, although both possible and actually in use) to continuously build the simple "current version" from a filesystem, without any sort of VCS backup, or version snapshotting. A terrible way to work, but it would still be CI. Andy Dingley (talk) 14:35, 9 April 2017 (UTC)

CI is not about automated building. Martijn Meijering (talk) 14:44, 9 April 2017 (UTC)

BTW, I recommend https://martinfowler.com/bliki/ContinuousIntegrationCertification.html, especially footnote #3. Martijn Meijering (talk) 15:13, 9 April 2017 (UTC)

Of course CI relies on automated building (as in, this is essential, unlike VCS which is merely wise). CI is the process of frequently (Fowler says daily as a minimum) integrating all developers' work to a single codebase, automatically building it and testing it. Andy Dingley (talk) 15:41, 9 April 2017 (UTC)

The automatic building and testing is indeed highly recommended, but not part of the definition. See his footnote #3. I'm trying to understand the objections to calling CI a version control strategy. Is the objection that it is more than that? Or do we disagree that the practice of merging to trunk at least once a day can reasonably be described as a version control strategy? Martijn Meijering (talk) 15:46, 9 April 2017 (UTC)

I can't understand what your objection based on footnote #3 is?

It is fundamental to CI (in Fowler's model) that this is performed on the development trunk. The point is that isolated developers, isolated from this trunk, lead to major reintegration problems if they're not reintegrated at least daily. So whatever else, there must be no more than one trunk, with no more than a day's drift apart.

A VCS is some system for managing historical versioning of the same entities. Anything that can't do this (i.e. the ability to extract any identifiable historical version, on demand) is not a VCS. No matter what else it might do.

Integration can be done without a VCS. It's possible (but inadvisable these days) to integrate the trunk by simply copying the latest file versions, just as a filesystem, without needing a VCS. This was indeed the practice at one time.

So CI is integrated, frequent, and extends through the build process as far as some sort of smoke test. This is Fowler's definition. Hamble's definition is beyond that, as it also requires the ability to rapidly fix a broken build (which requires VCS as making a regression possible, rather than a vain optimistic hope of hero-coding a fix). I'd grant that an "automated" build might not be a strict requirement, but then neither is formal VCS. If VCS thus isn't an absolute requirement, then I can't see how CI could be definable as a VCS strategy. Andy Dingley (talk) 19:55, 9 April 2017 (UTC)

Before coming back to your points, let me give a little background about where I'm going with this, in the hope that will help. I'm mostly concerned about what Fowler calls semantic diffusion. Over time a larger group of people than the original proponents of CI and their early followers have extended and sometimes outright changed the interpretation of the term CI to the point that it is no longer compatible with the original meaning. We should probably explicitly mention this and mention various points of view.

The original meaning of CI was 1) all code that is written is merged into trunk within a day at most (Kent Beck explicitly said a daily build wasn't enough) and 2) trunk stays shippable / potentially shippable or something very close to it. For many people 2) is implicit in 1) as for them it goes without saying that merging should not break trunk ('no junk on the trunk'). This is also true for people who advocate say GitFlow. Automated unit tests and integration tests are an obvious safeguard that are helpful here, but Beck explicitly says that these automated tests aren't part of the definition of CI. He does strongly recommend against not using them. Note however that even these recommended automated tests do not require a build server and for the first five years or so of XP's history build servers weren't used. The practice was to run the tests locally before committing/merging. I disagree automated tests are part of the original definition of CI (although not having them was strongly discouraged) and the same goes for build servers. They are an excellent and highly recommended practice however.

Then at some point build servers became very popular in XP circles (they had been used elsewhere long before). As more and more people got interested in what was then called agile 1) was forgotten, 2) was still applied on trunk but people added practice 3) automated build servers to the definition and also typically didn't always run all tests locally before committing and accepted builds that were slow and stayed broken for long periods of time. As a result the new definition was incompatible with the old and led to situations that were highly undesirable from the original point of view.

So summarising, while XP proponents today advocate doing 1), 2) and 3) they only include 1) and 2) in their definition of CI. Many other people advocate 2) and 3) and call that CI, and are against 1). Some advocate only calling all three together CI, with just 1) and 2) referred to as Trunk-based development.

Coming back to your points: we agree that being no more than a day away from trunk is crucial. We agree that an automated VCS is not strictly necessary, some sort of manual system might suffice. I would go further than saying it's inadvisable, I'd say it's almost unworkable if you have multiple people practicing collective code ownership, merciless refactoring and working in thin vertical slices as in XP (although those are separate practices that are not included in the definition of CI). Martijn Meijering (talk) 20:26, 9 April 2017 (UTC)

Misleading phrase

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:

1. "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
2. "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)

@Florian Finke: Your comments seem reasonable. WP:SOFIXIT. Walter Görlitz (talk) 14:28, 26 August 2019 (UTC)

Trying to understand this concept

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)