Can Salesforce co-exist with Continuous Integration?

Do we have the right to redefine industry-accepted concepts to fit OUR industry?

The other day I posted about the original definition of Continous Integration (CI) and how, based on that definition, most Salesforce teams will never be able to practice CI correctly.

The feedback I got (and I expected) was that the definition was too rigid. The truth is, I didn't come up with this definition. It was Kent Beck when I was six years old, and then Martin Fowler wrote about it again when I was 16 years old...

See, when these (very respected by me) individuals wrote about these concepts, they weren't thinking of Salesforce. They weren't imagining that one day an admin could create a complex piece of automation with drag-and-drop components (flows) or that you could create database tables and triggers with a few clicks.

They weren't also imagining that not everything could be tested (is anyone testing validation rules with apex?) or that the tests that do exist (apex tests) can take a very long time to run (it's async, salesforce will run them when they want).

They wrote about these concepts based on the type of software they worked on.

The type of software we work on is very different. Yes, many of the concepts still apply, and business applications can benefit A LOT from these concepts (that's why Salto exists), but not everything fits 100%.

So, would it be correct for us to redefine what CI looks like in the Salesforce world without having to shoehorn concepts from a different way of delivering software?

What do you think?