3 ms·

"Continuous integration" just means "automated tests on every push", and no longer means anything much to do with integration, which I always found kinda funny.

"Continuous integration" just means "automated tests on every push", and no longer means anything much to do with integration, which I always found kinda funny. It sometimes even means automatic running of scripts that aren't even tests, like automatically generating html from markdown on push. You could say that's continuous deployment, not CI, but you'd be fighting a losing battle. The yml file you wrote to run the deploy, what do you call it? It's a "CI script".

chriswarbo 4y ago
> no longer means anything much to do with integration, which I always found kinda funny. I thought the point of CI was to avoid (what we would now call) long-lived feature branches; e.g. a team spending 6 months on their own copy of a codebase, then struggling to merge it back into the mainline when finished. In other words, CI isn't just about running tests on push; it's about the frequency of pushes, often several times a day. Perhaps it's a good thing that such practices have become so ubiquitous (largely thanks to DVCS) that we don't really think of the alternatives any more :)
- munch117 4y ago
  When the term 'continuous integration' was originally conceived, the point was to avoid branching altogether. It was not features branches that was the problem (there was no such thing at the time), the problem was synchronising work between groups that were working on different parts of the same application. So the original CI server concept was that everyone would get a nightly update. Having a branch run for even 2-3 weeks means that you are not practicing continuous integration ... as originally conceived. I'm not convinced that it's a good thing that you and so many others have stopped questioning feature branching.
  - pards 4y ago
    >> Having a branch run for even 2-3 weeks means that you are not practicing continuous integration ... as originally conceived. Unless you're updating the feature branch from the main branch frequently (at least daily), thereby continuously integrating your code from the mainline. Problems arise when everyone's working on their own long-lived feature branch and the mainline doesn't move until they all try to merge their feature at the end of a sprint. Refactoring makes this worse.

chriswarbo 4y ago

> no longer means anything much to do with integration, which I always found kinda funny. I thought the point of CI was to avoid (what we would now call) long-lived feature branches; e.g. a team spending 6 months on their own copy of a codebase, then struggling to merge it back into the mainline when finished. In other words, CI isn't just about running tests on push; it's about the frequency of pushes, often several times a day. Perhaps it's a good thing that such practices have become so ubiquitous (largely thanks to DVCS) that we don't really think of the alternatives any more :)

munch117 4y ago
When the term 'continuous integration' was originally conceived, the point was to avoid branching altogether. It was not features branches that was the problem (there was no such thing at the time), the problem was synchronising work between groups that were working on different parts of the same application. So the original CI server concept was that everyone would get a nightly update. Having a branch run for even 2-3 weeks means that you are not practicing continuous integration ... as originally conceived. I'm not convinced that it's a good thing that you and so many others have stopped questioning feature branching.
- pards 4y ago
  >> Having a branch run for even 2-3 weeks means that you are not practicing continuous integration ... as originally conceived. Unless you're updating the feature branch from the main branch frequently (at least daily), thereby continuously integrating your code from the mainline. Problems arise when everyone's working on their own long-lived feature branch and the mainline doesn't move until they all try to merge their feature at the end of a sprint. Refactoring makes this worse.