Brazeal: How your org predicts your CI/CD pipeline
Jun 08, 2023 • 5 Minute Read
I’ll make you a bet. Tell me how your dev and ops teams work together, and I’ll tell you what your CI/CD pipeline looks like. That’s because CI/CD is the purest expression of Conway’s Law. Your CI/CD pipeline will be broken and messy in exactly the same ways your engineering org is broken and messy. That's how you get "pipelines" like this: 
OK, maybe that's a little exaggerated (though, in my experience with large enterprises, not much). But the flip side is certainly true: once you get your communication right, you can start seeing the benefit from CI/CD that you always hoped for. Not convinced? Let me show you some patterns. Cold War Remember that CI/CD pipelines exist to smooth and accelerate the flow of code from development through operations and QA into production, by automating manual steps and increasing confidence in releases. It’s the exact opposite of the waterfall release approach still practiced by many large organizations, where developers throw code “over the wall” to ops. Devs don’t get access to production, and ops doesn’t have much inside knowledge of how the code works. Let’s call this the “Cold War” pattern: 
It’s a bit amazing that a Cold War org would even think about implementing CI/CD. But they’re as likely to throw around the buzzword as anybody else. And that leads to extra admin overhead on top of increased manual labor when the new automation breaks down. Basically, just the old waterfall process with extra steps. You can’t get rid of the wall in your release process without getting rid of the wall in your organization. Gumbo Mmm, gumbo. Whereas ops tends to stifle development velocity in a cold war, a gumbo organization is a febrile swamp of developer activity. You see this in a lot of growing startups. The engineering team gets too large to sustain a simple release process, and what ensues is chaos. Without clear security guidelines or cloud operations training for developers, it’s way too easy to take down production or expose an S3 bucket with a rash config update. If the cold war is discontinuous integration, this is more like continuous disintegration. 
Smart people work in the gumbo. Some great CI/CD pipelines might be floating below the surface. But there’s no way to discover and share that knowledge across the company. Thankfully, the gumbo stage is so unstable that nobody can possibly mistake it for a good thing, so the organization quickly congeals into... The Blob The Blob coalesces at a higher state of maturity than cold war or gumbo. Someone realizes “We need standards! Guidelines! One tool to rule them all -- that will stop this madness!” So they institute a central DevOps team comprising the best infrastructure engineers on hand. The central team creates a pipeline infrastructure everyone is supposed to use. This might be as simple as a shared Jenkins instance. It might be as complex as an AWS account vending machine linked to a series of dynamic CodePipeline templates. 
But will other teams actually use the central pipeline? Some will! They will find their use cases a good fit for the generic solution and get absorbed into the blob. Other teams, however, will find that their application needs a different approach. They’ll use the central solution suboptimally, or worse, ignore it and spin up their own clandestine CI/CD workarounds -- shadow IT in the shadow of the blob itself. The Umbrella The blob wants you to think it is the only way to success. This is the power of the blob, why so many teams get stuck in it indefinitely. But the blob is wrong. Where mature organizations end up, not just in CI/CD but with cloud adoption in general, is a place where they enable individual teams to succeed on their own terms, while still giving them the guardrails and training they need to meet the org’s standards of cloud excellence. That means having a central architecture board and a security team to create clear guidance -- what one ACG customer I talked to recently calls “cloud non-negotiables.” It means embedding your cloud experts with product teams who need hands-on support to transition from cloud novices to gurus. And, yes, it means ensuring that everybody speaks the same cloud language through training and certification. You could call this the umbrella pattern. Every product team is different: the umbrella of cloud fluency covers them all. 
Now I’ll call in that bet: did I describe your organization? Or are you seeing other patterns? Hit me up on Twitter and let’s keep the conversation going.
OK, maybe that's a little exaggerated (though, in my experience with large enterprises, not much). But the flip side is certainly true: once you get your communication right, you can start seeing the benefit from CI/CD that you always hoped for. Not convinced? Let me show you some patterns. Cold War Remember that CI/CD pipelines exist to smooth and accelerate the flow of code from development through operations and QA into production, by automating manual steps and increasing confidence in releases. It’s the exact opposite of the waterfall release approach still practiced by many large organizations, where developers throw code “over the wall” to ops. Devs don’t get access to production, and ops doesn’t have much inside knowledge of how the code works. Let’s call this the “Cold War” pattern: It’s a bit amazing that a Cold War org would even think about implementing CI/CD. But they’re as likely to throw around the buzzword as anybody else. And that leads to extra admin overhead on top of increased manual labor when the new automation breaks down. Basically, just the old waterfall process with extra steps. You can’t get rid of the wall in your release process without getting rid of the wall in your organization. Gumbo Mmm, gumbo. Whereas ops tends to stifle development velocity in a cold war, a gumbo organization is a febrile swamp of developer activity. You see this in a lot of growing startups. The engineering team gets too large to sustain a simple release process, and what ensues is chaos. Without clear security guidelines or cloud operations training for developers, it’s way too easy to take down production or expose an S3 bucket with a rash config update. If the cold war is discontinuous integration, this is more like continuous disintegration. Smart people work in the gumbo. Some great CI/CD pipelines might be floating below the surface. But there’s no way to discover and share that knowledge across the company. Thankfully, the gumbo stage is so unstable that nobody can possibly mistake it for a good thing, so the organization quickly congeals into... The Blob The Blob coalesces at a higher state of maturity than cold war or gumbo. Someone realizes “We need standards! Guidelines! One tool to rule them all -- that will stop this madness!” So they institute a central DevOps team comprising the best infrastructure engineers on hand. The central team creates a pipeline infrastructure everyone is supposed to use. This might be as simple as a shared Jenkins instance. It might be as complex as an AWS account vending machine linked to a series of dynamic CodePipeline templates. But will other teams actually use the central pipeline? Some will! They will find their use cases a good fit for the generic solution and get absorbed into the blob. Other teams, however, will find that their application needs a different approach. They’ll use the central solution suboptimally, or worse, ignore it and spin up their own clandestine CI/CD workarounds -- shadow IT in the shadow of the blob itself. The Umbrella The blob wants you to think it is the only way to success. This is the power of the blob, why so many teams get stuck in it indefinitely. But the blob is wrong. Where mature organizations end up, not just in CI/CD but with cloud adoption in general, is a place where they enable individual teams to succeed on their own terms, while still giving them the guardrails and training they need to meet the org’s standards of cloud excellence. That means having a central architecture board and a security team to create clear guidance -- what one ACG customer I talked to recently calls “cloud non-negotiables.” It means embedding your cloud experts with product teams who need hands-on support to transition from cloud novices to gurus. And, yes, it means ensuring that everybody speaks the same cloud language through training and certification. You could call this the umbrella pattern. Every product team is different: the umbrella of cloud fluency covers them all. Now I’ll call in that bet: did I describe your organization? Or are you seeing other patterns? Hit me up on Twitter and let’s keep the conversation going.
ACG for Business helps everyone in your organization speak the language of cloud, so you can break down barriers and build value faster.
