Beware of Fake CI/CD Promoters
Some just like talk about "CI/CD", but fear when seeing real CI/CD, e.g. Daily Production Releases enabled by executing a comprehensive E2E (UI) suite as regression testing regularly.
Recently, I came across a LinkedIn Post by a claimed “Thought Provoker / COO — AI / Edge Computing” on “Continuous Deployment”.
“I’m still not sure why so many Enterprises reject this practice.”
“Continuous Deployment is a practice that doesn’t come with the headaches and the worries of Releasing. It’s so normal that any change gets pushed all the way into Production that the asking “When can we go into Production?” becomes redundant. You’re doing it multiple times per day.”
“on the Green Field, why would you even want to go down the thorny road of pain and nightmares called “Deployment Schedule” — when there’s a simpler, faster, more reliable and less expensive alternative?”
“I believe Continuous Deployment is a “best practice” in most modern environments”
All sounds positive, right?
Like most software professionals, I agree with the above. I have been practising “Daily Production Releases” for over a decade. I added my comment to highlight the importance of E2E test automation in Continuous Deployment.
“Company executives love CD (Continuous Delivery, deployment to production), they like to talk “release early; release often”. Also, deployment often, technically, is easy. However, the real challenge is Test Automation, especially End-to-end test automation. Many companies, tried CD without the safety of E2E test automation, boom, regression errors in production. Then, a blame game, eventually quiets stop CD. Because most senior software engineers do not admit they lack E2E test automation knowledge, in fact, far above their capability (check out the quotes from software legends in this Medium Boosted article)”
Then, a confusing reply from the post author.
Please note that my comment does not disagree with his post, rather pointing out the obvious and easy-to-understand fact:
You cannot do continuous deployment (to production) unless you have a solid and repeatable End-to-end test automation process.
The reply from the post’s author is vague and confusing (I did not know the word ‘dichotomy’ before) and strays from the two key terms in my comment: "Automation" and "End-to-end."
From my experience, many so-called “software architects” (ever heard of the term “Architecture Astronaut”?) tend to use complex language and vague statements to mask their lack of understanding. A cunning way to cover their incompetence is to complicate simple things.
Over the years, I’ve come to realize that “some people actually fear what they claim to love”, as an ancient Chinese idiom puts it.
Over the years, I’ve encountered several fake ‘architects’ who falsely claimed CD experience — pure lies. The reason is simple: they’ve never experienced Automated E2E (UI) regression testing. Check out this story: A Software Architect Attempted to Undermine Continuous Testing — Later Eagerly Sought My Mentoring on BuildWise Before My Departure.
I am sure many readers have been hearing “CI/CD”, “CI/CD Pipeline”, and “Continuous Deployment” many times (or even daily), but what are the actual outcomes?
Let’s resort to Martin Fowler’s original CI article (2000–09–10), which started all CI and CD.
“Software development is full of best practices which are often talked about but seem to be rarely done. One of the most basic, and valuable, of these is a fully automated build and test process that allows a team to build and test their software many times a day.”
“It stresses a fully automated and reproducible build, including testing, that runs many times a day.”
“Once Ant has done the compiling and deployment”
See, the concept of “Continuous Deployment” is at least 24 years old (a long time in software) and not new at all.
Why are there still many CI/CD talkers? Because real implementation of CI/CD relies on solid E2E test automation (obvious, once it is pointed out, isn’t it?), which is far beyond most software teams’/companies' capability.
In an interview in October 2019, Lisa Crispin, the co-author of the Agile Testing book, said this: “They (Jez Humble and David Farley) asked me to be a technical reviewer for their manuscript (the famous Continuous Delivery book) … I read it. It’s a book about testing, you know, the whole book is really about testing. That’s the heart of continuous delivery. Jez Humble is very supportive of my saying that.”
Let’s quickly revisit the comment from that fake CI/CD guru.
“Testing (of course, test automation, especially E2E test automation) is the heart of CD” according to the absolute authority of CD, not “false dichotomy”. See, how wrong can a faker be?
In case fake CI/CD ‘experts’ argue “Robert C. Martin might mean unit tests, not E2E tests”. Check the quote below.
From my own experience with CI/CD and observations over the past 18 years, attempts without E2E test automation either fail or end up being largely irrelevant.
However, when real, daily execution of E2E test automation is integrated into CI/CD, the outcome is entirely different. Lisa Crispin’s other post in 2010, titled “The Team’s Pulse: CI/Build Process”, expressed the importance of CI and testing to a software team.
So-called conventional-perceived CI/CD is very easy, it is often a selection criteria listed on junior software engineer job ads. But, was there real continuous delivery to production?
But real E2E test automation, just say, 50 E2E user-story level tests running a regression testing daily, is very rare.
For doubters on “Include comprehensive E2E (UI) test automation a part of CD process”, check out “Showcase a 500+ End-to-End (via UI) Test Suite: E2E Test Automation is Surely Feasible for Large/Complex Apps”.
In summary, fake CI/CD/DevOps Engineers fear E2E test automation. For motivated readers who want to achieve real CI/CD but lack E2E test automation knowledge, check out the following learning resources.
Related reading: