Continuous Delivery For the Enterprise

The practice of Continuous Delivery is frequently equated with hip startups and bleeding-edge Silicon Valley shops building consumer facing web sites. It’s what those super cool, super smart guys at Etsy and GitHub do and they do it because that’s how they stay competitive.

But what if you work in a place that doesn’t need to do A/B testing of the latest feature set and isn’t driven by competition to deliver a new capability every other week? What if you work for the dreaded “Enterprise”? Should you still do CD?

From my perspective, the answer is yes.

Now, I could tell you that CD is where the world is going and if you don’t get with the program, you’ll eventually fall behind. Or I could tell you that good engineers will soon come to expect it and to attract the best you’ll need to step it up.

But, I won’t tell you about those things. Instead, I’d like to talk about the real reason to adopt CD for the Enterprise and it can be summarized in two words: forcing function.

Keeping Code Healthy

There’s nothing like the prospect of pushing every change directly to production to make sure that your coding house is in order. For example, conversations about high test coverage can no longer end in “This is an awesome idea and we should totally do it, but let’s just get through this next couple of weeks first, k?”.

Another thing that is no longer an option is manual steps during deployments. The answer to “Is our pipeline automated?” can no longer be “Yes, our pipeline is totally automated except for needing to manually verify that production still works after deployment.”

Breaking Down Silos

It’s no secret that a typical Enterprise is frequently littered with warring skill tribes (i.e. QA vs. BA vs. devs vs. ops). Managers work hard to carve out their fiefdoms and even harder to protect them. Hence, the flow of work is constantly choked by policies and procedures.

Well, fiefdoms and Continuous Delivery aren’t really compatible. To conceive, design, implement, test, and deploy code in a CD environment requires a level of collaboration that is simply untenable if your organization resembles 15th century Italy.

So, if you’re serious about CD, fiefdoms will need to go. And, in all likelihood, some of those who helped build said fiefdoms will need to go too.

Raising The Talent Bar

Working in a CD environment requires capable people. Not superstars perhaps, but people who generally know what the right thing is and can be trusted to do it.

Unfortunately, the level of talent in a typical Enterprise leaves a lot to be desired. Sure, there is a (usually small) group of people who know what they’re doing. But there’s also a (much larger) group who isn’t exactly hurting, but isn’t helping much either. And then there’s a (usually not nearly as small as it should be) group of people who are essentially sabotaging the whole thing, typically due to lack of ability.

And so, as the talent bar goes up, you will need to go though a painful adjustment. Some will not survive the transition, others will thrive. But you will eventually get through it and will be better off for it.

Final Thought

Doing CD is hard, Enterprise or not. It requires a constant level of vigilance, commitment, and competence from everyone involved in building software. Yet because CD impacts so many aspects of an organization in a positive way, it should be seriously considered, Enterprise or not.

You may also like:

• How Capable Is Your Technology Team?
• The One Million Dollar Team
• The Software Team
• The Microsoft Tax
• Management Anti-Patterns on Product Teams

• ContinuousDelivery
• development
• enterpise
• team

Did you love / hate / were unmoved by this post?
Then show your support / disgust / indifference by following me on Twitter!