Invitation to Review the CI/CD Engineering Anti-Patterns

Over the last several years, I have been working on a book around a subject that has stayed very close to my engineering work and research:

Continuous Integration, CI/CD, and Engineering Anti-Patterns
Why Continuous Integration and Delivery Fail and How to Engineer Better Outcomes

The book started from a simple observation.

We often discuss CI/CD in terms of pipelines, automation and tools. But in practice, many of the problems we see in Continuous Integration do not originate inside the pipeline itself.

They can begin much earlier — in unclear engineering intent, architecture, requirement slicing, branching, test strategy, environments, ownership, security, organizational behavior, measurement, or simply in the way teams learn from recurring failures.

That became the central idea behind the book:

CI/CD should be understood as a connected engineering system, not only as a pipeline.

What the Book Covers

The current manuscript brings together 45 engineering anti-patterns across 10 engineering themes.

The book first establishes the broader engineering context and introduces a system view called PULSE, looking at CI/CD through five dimensions:

• Purpose & Culture
• Underlying Engineering Foundation
• Lifecycle Flow
• System Assurance
• Evidence & Evolution

From there, the book moves into the individual anti-patterns.

Some examples include:

• CI Without a North Star
• The Architecture-Blind Pipeline
• The Branching Maze
• The Accidental Test Pyramid
• The Flaky-Test Fog
• Coverage Theatre
• Infrastructure as an Exception
• Security and Safety Outside CI
• The SBOM Afterthought
• The Pipeline Without Telemetry
• AI as a Coding Add-On
• The Invisible Value Stream
• Automation Without a Test Architecture
• Testability as a Late Concern
• The Big-Bang Deployment

Each anti-pattern follows a common approach:

Recognize → Diagnose → Transform → Assess → Mature

The intent is not only to describe what is wrong.

The more important questions are:

• What does the pattern look like in real engineering work?
• Why does it keep happening?
• What evidence should we inspect?
• What part of the engineering system needs to change?
• How do we know whether the change actually improved the outcome?

Why I Am Sharing an Early Review Manuscript

The complete book is now fairly substantial, and I am continuing a detailed line-by-line review and refinement.

Before taking it further, I wanted to create a shorter Early Review Manuscript that gives reviewers enough of the book to understand the thinking without requiring them to read the complete manuscript.

This review edition includes the overall book philosophy, the system model, the complete list of 45 anti-patterns, the chapter structure, and a representative selection of anti-patterns in greater detail.

I am sharing this primarily to learn.

If you work in software engineering, architecture, CI/CD, DevOps, quality engineering, platform engineering, security, embedded systems, engineering leadership, academia, or related areas, I would genuinely value your perspective.

Review Manuscript:
Read the Early Review Manuscript

What Feedback Would Be Most Helpful?

• Does the central idea of treating CI/CD as an engineering system resonate?
• Are there important engineering anti-patterns or perspectives that appear to be missing?
• Are some anti-patterns overlapping or better combined?
• Is the Recognize → Diagnose → Transform → Assess → Mature structure useful?
• Is the level of technical depth appropriate for practitioners?
• Are the examples and terminology understandable across different engineering domains?
• What could make the book more useful to an engineer or engineering leader trying to improve a real system?

You do not need to review every page. Even comments on one section or one anti-pattern would be valuable.

A Small Request

If, after reading the manuscript, you believe the book can make a useful contribution to the engineering community, I would also be grateful for a short reflection or endorsement.

It does not need to be promotional. A few genuine lines about what you found useful, different, thought-provoking, or practically relevant would be much more meaningful.

Share your review / reflection:
Share Your Feedback

I am still refining the manuscript, so critical feedback is equally welcome. In fact, this is exactly the stage where it can help the most.

Thank you to everyone who has already challenged the ideas, reviewed individual sections, shared engineering experiences and helped shape the thinking behind this work.

There is still work to do, but I felt this was the right point to open the manuscript to a wider group of reviewers.

Anish Cheriyan, PhD