Discount on my website!

Buy this color paperback. Then, send me a note at "" with your shipping address. 

Pay with PayPal or a debit/credit card

November 2, 2017


The Power Of Continuous Delivery In DevOps

Reduce Difficulty By Increasing Frequency Of Your Product Releases

Dimension: 8.5" x 11" (21.59 x 27.94 cm) 

This book has TWO purchase options on Amazon. Grab your copy now!


Option 1) Color eBook. 

Option 2) Bundle of color paperback and color eBook.  

View, print and download color-coded diagrams from the links provided at the bottom of this page.

Book Description

I have had the privilege to witness tech organizations going through transformations of culture that build trust and improve efficiency. I have had the pleasure of working with some of the brightest minds and have had the good fortune of seeing my decisions stand the test of time, and in some cases not as much.   

Processes, amongst other things, can exponentially improve organizational culture. This book lays the foundation of building resilient processes for transformational leaders who aspire to drive culture change in their organizations. The principles of DevSecOps, Continuous Integration and Continuous Delivery form the recipe for success, and Continuous Improvement is at the heart of it.   

As you plow through the chapters of this book, you will virtually experience the thrills and the shivers of leading a crucial transformational change. And you will be able to define the next chapter of your very own journey.   

This is how I have structured the book: 

Chapter 1: Introduction

Eases my readers into understanding and appreciating a Continuous Delivery Pipeline, extends the concepts to Continuous Everything and Everyone, and gives a brief introduction about myself.

Chapter 2: Continuous Delivery As A Domain

Domain-driven design (DDD) is known to be overkill for simple problems. After careful consideration of the issues that plague product releases (software, firmware, embedded systems, Internet of Things, * as a service, and the like), I decided to model the Continuous Delivery Pipeline as a domain.  

Chapter 3: Pipeline Domain Model Integrity

In an academic setting of model-driven-development, we try to maintain a consistent and unified model throughout the teams. In reality, there could be many teams who work on different parts of the Continuous Delivery Pipeline ecosystem and the model tends to fragment. However, aspects of the model that are important should stay unified and other parts could be offered for customization. The product architect walks a fine line on how much fragmentation is too much.   

Chapter 4: Continuous Analytics And Insights

Teams are required to zoom in and solve hard problems every day. They need to tease offensive incidents apart to analyze the root cause, and ensure that these never happen again. While it is paramount to be able to get down on our knees and dig in, it is just as important to be able to zoom out and fathom the big picture. We need to see the forest through the trees. We should emphasize on learning patterns and trends over a period of time that offer direct insights into our business. These help us make tough calls that pay rich dividends in the long run.   

Chapter 5: A DevSecOps Seed Backlog

A single prioritized Product Backlog is a key driver to an organization’s growth and sustainability. A traditional Product Owner leans heavily towards development and quality, and sometimes overlooks the security and operational aspects of releasing products to their customers. There could be Product Owners in the Security and Operations teams, who are entrusted to fill in this void; however, multiple Product Owners tend to come up with separate copies of a “single prioritized backlog”, thereby leading to fragmented and frictional execution. This chapter enables Product Owners to address epics related to not just Development but also Builds, Tests, Configuration, Deployment, Monitoring, KPIs, Operations, Network, Security and related issues that help teams experiment safely and turn great ideas into products. More importantly, this helps teams recover fast from not-so-great ideas.   

Chapter 6: The Twelve-Factor Pipeline

The Pipeline is an incarnation of Process-As-Code. It is a product in it’s own right. It is a first-class citizen, or else why should we release quality products to our customers through it?   Sometimes we fail to do due diligence in treating the Pipeline as an application, since it is not our core domain. However, Pipelines reflect hygiene (or the lack of it) and impact culture, productivity and velocity of our teams. Inspired by The Twelve-Factor App, the Twelve-Factor Pipeline establishes the same gold standards for the Pipeline application, as are applied to the products that flow through the Pipeline.  

Chapter 7: Segregation/Separation Of Duties

Segregation of duties or separation of powers is a controversial topic in organizations that have dwelled on a legacy hierarchy long enough to confuse separation of duties with separation of departments. These organizations experience severe delays in implementations of Continuous Delivery Pipelines. Also, degrees of separation in some organizations are high, thus causing folks who lead digital transformation initiatives like Continuous Delivery, to be far removed from the problems. Pipelines tend to relentlessly gnaw through departments and silos, and rightfully so, and can be seen as posing risk to the business and our customers. This chapter establishes guidelines on how we should implement Continuous Delivery Pipelines that improve speed, quality and predictability without risking business.    

Chapter 8: Myth Busters

Some organizations fall prey to age-old beliefs that have inherent flaws. Old-school technologists delay ushering in the new by championing these outdated beliefs. This results in modernized approaches getting the boot and new gen tech leads stumbling over bureaucracy and red tape.This chapter pulls up the most damaging myths and addresses the elephant(s) in the room. Education is key, and we should discuss painful issues in an open forum till the light bulbs go on. We should invest in having one-on-ones with traditional and orthodox technologists, and find a happy medium to enable experimentation of new and daring ideas. As a last resort, if experimental ideas continue to get trampled under myths, we should take firm and disciplinary measures to get the organization back on track for a successful digital transformation.  

Chapter 9: Resources

Lists a set of resources where you can find great information. 

Download Figures

Firmware and Embedded Systems (png)


Pipeline Domain Services (png)


DDD Context Map - Product Composition Anti-Pattern (png)


Pipeline - Fragmented Model (png)


Continuous Delivery Pipeline - Domain Model (png)


Hand-off Anti-Pattern (png)


Test Architecture for Microservices (png)


PubSubArchitecture (png)


Pipeline Asset - Circuit Breaker (png)


KPIs (png)


DDD Context Map - Customer Supplier Pattern - Intranet Model (png)


DDD Context Map - Conformist Pattern - Internet Model (png)


Anti-corruption Layer (png)


Continuous Delivery Pipeline - Simplified Domain Model (png)


Concept 2 Cash (png)