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:

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.