Until recently, I was using the wrong definition of Continuous Integration. You probably are, too.
This is a bit of an embarassing mistake, at least for me, because I’ve heard the proper definition many times. And I talk about, and advocate for, CI, all the time.
If you had asked me, I probably would have said something like “Automatically test your code, before it’s merged.”
Interestingly, the simplest definition of continuous integration says nothing about testing—automatic or otherwise. Quoting Martin Fowler:
Continuous Integration is a software development practice where members of a team integrate their work frequently, usually each person integrates at least daily - leading to multiple integrations per day.
This means that even with a fully-automated unit, integration, API, and end-to-end test quite with 100% coverage, you’re not doing CI if you have a long-lived feature branch. Or if multiple developers contribute to the same branch.
It also has the surprising implication that you could theoretically have continuous integration with no automated tests. This is a thought experiment I’ve played with before.
To be fair, the very next line from Fowler says “Each integration is verified by an automated build (including test) to detect integration errors as quickly as possible,” so please don’t go telling him (or anyone) that I think we shouldn’t be doing automated tests!
If you found this content interesting, I expanded on a lot of this in yesterday’s session of my free remote course “Ship better code faster”. You can watch the replay here: https://www.crowdcast.io/e/j7a4lakq/3
Top comments (0)