> Seems orthogonal to me. You can run CI on a branch.
Funny how some terms can be diffused enough over time to come to mean almost the opposite of what they originally meant. Continuous Integration is about integrating continuously. "the practice of merging all developer working copies to a shared mainline several times a day." i.e. everyone commits to master multiple times a day.
Then tooling gets built to facilitate this way of working. People start confusing build tooling with CI the practice. Eventually that tooling gets used to support people working in continual isolation on feature branches. People start calling this practice CI even though there's no integration in sight.
Of course true CI isn't applicable for all contexts. Draft pull requests look like a great tool for where CI is impractical.
Merging into a single branch isn’t the definition that people like ThoughtWorks seem to use. They just talk about integrating into a shared respository, not specifically a shared branch.
The CI system then does the work for you to test that on top of master. You’re talking about developers doing things that the CI system is there to do.
CI only seems to make sense to me when talking about a single branch ("master", "trunk") into which all changes are frequently merged. FWIW, also Wikipedia describes it as "merging all developer working copies to a shared mainline", the latter being a branch, not repo.
Otherwise, you still might test indvidual feature branches on top of master, but that wouldn't prevent any conflicts between several of the pending branches. One could think of a system that continuously tests all possible combinations of all pending feature branches to spot any conflicts before actually integrating them. Not sure whether such thing exists, though, or whether it'd be very practical.
Funny how some terms can be diffused enough over time to come to mean almost the opposite of what they originally meant. Continuous Integration is about integrating continuously. "the practice of merging all developer working copies to a shared mainline several times a day." i.e. everyone commits to master multiple times a day.
Then tooling gets built to facilitate this way of working. People start confusing build tooling with CI the practice. Eventually that tooling gets used to support people working in continual isolation on feature branches. People start calling this practice CI even though there's no integration in sight.
Of course true CI isn't applicable for all contexts. Draft pull requests look like a great tool for where CI is impractical.