Continous Integration and Continous Delivery - Pitfall pattern when building and deploying software for the enterprise

Part 2: The Domains

The problematic pattern described in my previous post is more or less the same pattern you see when a code base is not probably maintained and refactored over time. 

It becomes, big, huge, ugly and utterly complex making every new feature, bug fix, refactor or tweak a combined effort between multiple individuals and the process spawns weeks of implementation and testing, instead of hours. Always with a lot of bugs even though you use TDD/BDD/DDD/SBE/NDD etc.

And just think about how hard it is for new developers to get up to speed on systems like this.

So whats wrong?

Well, likely you have a flawed design/architecture which means you misunderstood the domain(s) or due to ridiculous deadlines, “I never had time to do refactoring” (shame on you) you skipped the much needed refactorings. Maybe you’ve just been on leave for 6 months and come back to find your nicely separated domains completely mutilated by developers who had no understanding of the domains and thought interprocess communication via email combined with direct access to a shared database was the best idea ever…

Anyway, you have a problem when Jack leaves the company and its a big problem.

My point is that you must regard your CI/CD pipelines as if they were individual pieces of highly complex software. Because they are.

This means that your build and deploy processes adhere to the exact same principles as are commonly considered good software architecture and design.

This is basic stuff that is extremely hard to achieve.

• It requires tons of domain experience (dev/ops)
• It requires the involvement of many people or at least a couple of individuals with way above normal intelligence to get it even remotely right and you do not have many of those around
• It can almost never be handled successfully by just 1 guy, like Jack

The place where people go wrong most of the time is, according to my own observations, with understanding that there are multiple domains when talking about CI/CD. On a larger scale i will claim that:

• The build process is one domain
• The deploy process is one domain
• These domains have nothing in common except a simple package contract

So with your CI/CD process, uses the same principles as you would with business software. To mention some of my favourites:

• Spot the domains
• Understand the domains
• Separate the domains
• Spot the subdomains
• Use SOC and SRP but on your subdomains, adjust
• SOLID
• TDD
• BDD
• DDD
• SBE
• NDD
• MSA (bad name imho, should be something with domains/subdomains instead, so developers are lead to think about the business and not the technical solution)
• etc.
• Whatever combination works for you :)

Remember when talking about CI/CD you are actually in YOUR OWN DOMAIN, no one knows these domains better than you and these are the domains that enable you to move securely and fast when developing software.

It's a must to understand, separate and continuos improve upon these domains.

Next: Part 3: Root Causes