Deploying to Production Frequently

Faster reaction times – The most obvious benefit is that it allows quick reactions to stimuli, both external and internal – whether it’s a market segment that takes a weird left turn, morphing that P5 feature into a company-saving imperative, or a researcher that uses your flagship application as an example of what-not-to-do at the security conference du jour. What business doesn’t want that?
 

Exposed inefficiencies and costs – Every software organization incurs a cost to ship the bits out the door. Often times, these costs aren’t entirely clear to the business. There can be all sorts of forces that obscure how much it really costs to ship a release. Deploying frequently makes this process apparent not only to the business itself, but to the decision makers. When constructing a pipeline, it will become clear where humans are involved, what bottlenecks exist, and what low-hanging automation fruit there is to pick. And once constructed, the pipeline creates a virtuous cycle. Clear incentives for a healthy software delivery dynamic now exist, replacing a nebulous discontent with how long and costly it is to release.

Reduced risk – For many organizations, there’s a non-trivial amount of pageantry around shipping a release. And why shouldn’t there be? New features are finally out to customers. Bugs are fixed. Everyone’s happy, right? The dark secret in many organizations is that shipping a release takes a huge amount of effort on the part of the QA and build/release teams. Under a frequent deployment model, software is “released” constantly (though not necessarily to customers). Therefore, the ceremony and the risk around releasing is reduced. If you’re relying on your release infrastructure daily, you will notice (and resolve!) its deficiencies much quicker than if the process is only undergone once every few months.

Flexible release options – Moving to a frequent deployment model requires the build-out of infrastructure, both in an operational context and a software architecture context. But once that’s done, it provides the business with more flexibility in how it delivers features and fixes. Specific sets of features can be released to specific customers, or released to a subset of customers, to ensure they function and scale as designed. Features can be tested and developed, but left dormant in the product, baking for multiple releases. Your marketing department wants that “big splash” at the yearly industry convention? With frequent deployment, it’s not only possible, it can become a trivial request.