If you are reading this post you know that both C’s in CI/CD represent “Continuous” (and if you didn’t already know that, your curiosity is admirable…and, no, “curiosity” isn’t the third C).
Getting to CI/CD can be a challenge, especially if it isn’t set up as part of the first release. (Challenge is not our third C, either, though it is becoming apparent there are many words that start with C related to software systems, so we’ll ignore the false possibilities from here on out). Adding to the procedural challenge of timing, there is also the conceptual challenge of semantics. Some organizations define the continuous Cs as every time a commit is made to the repository; others say it begins with a merge after a review; some say that if it is done “correctly” (are you still counting the “C”s?) there is no need for a review; still others will say that hourly (or daily, or twice daily, etc.) counts; some say you only really need I or D continuously (and others will certainly debate that); and there are bound to be more that don’t come to mind at the moment. What those contiguous definitions of continuous have in common is that they are all correct, depending on the context.
The cruel thing about continuous is that, technically, if it ever isn’t, it never was and cannot be again. Which is not correct, because even when done perfectly, there will be the occasional hiccup and things will need to be re-calibrated to continue being continuous.
Except when they don’t.
When they don’t, there can be several symptoms that are confused with causes. At some point, commits became synonymous with the cards on the Kanban. Sometimes it’s because management thought it would be useful to automate tracking with branches, or people used build failures as a measurement of skill rather than assignment of bug fixes, or PRs are preferred over testing—despite the fact that this approach often leads to more production issues and longer MTTR.
So what prevents those problems (and others) from discontinuing (or preventing the adoption of) CI/CD? It’s the third C, and…
The third C is Culture.
CI/CD requires the adoption of a “shift left” mentality, which in turn requires a culture of fearless experimentation where testing before committing is done as a point of pride, and every time the tests pass is a reason to commit (or “another test passes”, if you are following TDD). This also requires using feature flags that are either centrally managed (which supports runtime management in production) or developer managed, which requires automated testing of the flag.
A successful CI/CD culture depends on the team’s attitude—an attitude built on one part pride, one part professionalism, one part discipline (maybe two parts), and is most easily maintained when it includes the participation of leadership (perhaps the next post will be about the missing “P’s” in technology).
So, after that long walk through what was really a short concept, the key takeaway is that if your team is struggling with starting or sustaining a true (because there are many that are in name only, and you know which ones) continuous pipeline, focus on fostering a cultural shift within your team before investing in tools.
© Scott S. Nelson
