When Should Responsible DevOps Teams Increase Deployment Frequency

In my last few posts, I've been challenging the wisdom that more frequent deployments are better. I've also shared what DevOps teams must consider as prerequisites and processes beyond CI/CD to enable reliable deployments. Consider reading the following posts for more details:

You may also want to read one of my earlier posts where I ask whether continuous deployment is right for your business.

So the question I hope to help you answer today is, what frequency of deployment is best for your business and application? To determine this, consider answering the following questions:

Deployment Frequency ~ f(UN, TO, DBP)

The target frequency of deployment must take the following into consideration: (UN) end-user needs and competitive factors for customer-facing applications, (TO) technical deployment overhead and (DBP) the duration of time to execute post-deployment business processes. Specific questions you should answer to help answer the target duration between releases:

  • How frequently do end-users want new capabilities? Don't make the assumption that users want the workflow, user experience, or design of their applications changed super frequently. If the improvements you are targeting will require communications, training, and just adjusting to the changes, then deploying frequent changes can frustrate people. This is especially the case for enterprise applications deployed to a large number of people doing business-critical work. If you hange the tools and process too frequently then there will likely be frequent drops in productivity.
  • How much technical overhead is there in your end-to-end deployment process? Consider all the pre and post-deployment priorities and measure the applied effort. If the overhead effort is on par with the efforts invested in development activities, then you're deploying too frequently.  
  • How much business process overhead is there tied to deployments? There are likely communications and marketing efforts tied to the release of customer-facing applications. Deploying internal applications also requires communications and possibly training. The duration required to execute these activities can't exceed the time between releases, otherwise, one release's activities will bleed into the next one! 

How to Increase Deployment Frequency

If you want to deploy more frequently, then there are several options:

  • Reduce the technical overhead which is why having automated CI/CD, IaC and continuous is a critical ingredient.
  • Invest in feature flagging, branching, and other techniques to enable releasing critical fixes and minor improvements as a minor release while new capabilities, workflow changes, and major UX improvements are released in less frequent major releases. See my previous post on release management for more details.
  • Consider alpha and beta deployments, or deployments that are released to small segments of users to reduce the risk and disruption of frequent releases.

This is my last post on the topic of deployment frequencies. If you want to learn more about these practices, please consider downloading my white paper on StarCIO Agile Planning: The Missing Practices to Gain Alignment and Achieve Great Results.

No comments:

Post a Comment

Comments on this blog are moderated and we do not accept comments that have links to other websites.


About Isaac Sacolick

Isaac Sacolick is President of StarCIO, a technology leadership company that guides organizations on building digital transformation core competencies. He is the author of Digital Trailblazer and the Amazon bestseller Driving Digital and speaks about agile planning, devops, data science, product management, and other digital transformation best practices. Sacolick is a recognized top social CIO, a digital transformation influencer, and has over 900 articles published at InfoWorld, CIO.com, his blog Social, Agile, and Transformation, and other sites. You can find him sharing new insights @NYIke on Twitter, his Driving Digital Standup YouTube channel, or during the Coffee with Digital Trailblazers.