How can we help?

Design? Check. Strategy? Check. Bulletproof code? Check! People who can manage it in an agile and efficient manner? Check. Someone to help you create your next big product? Of course.


- 1201 18th St. Suite 250, Denver, CO 80202

Grand Rapids

- 125 Ottawa Ave NW Suite 270, Grand Rapids, MI 49503


BLOG:DevOps Core Tenet: Frequent Releases

DevOps Core Tenet: Frequent Releases

This is the second in a series of blog posts about our four core tenets of DevOps. For more information on our approach to DevOps, visit our DevOps page.

One of the biggest shifts in software in the past decade has been the shift in release cycles. In the past I’ve worked with many Fortune 100 organizations which had a 12-18 month release cycle for delivering new value for software. In today’s digital landscape users expect that an organization can deliver new value in 4-6 weeks. There is no way for traditional organizations to achieve this goal without an entirely new way to think about how value is delivered.

The lengthy release cycles of the past consisted of large monolithic updates to an existing solution. In addition to the development time, these organizations would also have to deal with extensive manual regression testing, purchase cycles for new infrastructure, as well as separate legal and compliance processes. When recently speaking with a client, he simply stated, “With our current process, the absolute fastest we can release something new is six months”.

The entire Continuous Delivery process is a new paradigm focused on radically altering the way organizations approach the pipeline of value delivery. By shifting to a model which values automation in provisioning, testing, and compliance you can ensure that your experience is releasable at any point. In this way, an agile release management team can effectively release new value to users every few weeks instead of every few quarters.


There is obviously a cost associated with adopting a new release and deployment methodology. Because of that, it is important to understand the justification for adopting a methodology that releases value to users in smaller more frequent releases:

  1. User feedback is integrated much earlier into the process. In a 12-month release cycle, you may not get valuable user feedback from real users until a year after something was created by the development team.
  2. It allows for agility to accommodate landscape changes in both business and technology. What if a major technical announcement from a company like Apple or Google happened today? What if your chief competitor develops a completely new type of digital touchpoint? How quickly could your organization respond? Successful organizations are those with an emergent approach to digital strategy, which allows for change within weeks instead of quarters.
  3. Risk is reduced by including smaller incremental releases over monolithic ones. Most organizations have a high degree of uncertainty with monolithic releases. Despite extensive manual testing, issues always seem to arise during the production roll-out. In some cases, this can lead to downtime or even having to revert to a previous release. If a new monolithic release substantially slows down the overall experience, good luck finding the offending portion of code. However, with smaller more frequent releases, these types of issues are identified much faster and are able to be resolved in a much more efficient manner.


There is a reason that nearly all modern digital organizations have abandoned lengthy release cycles and monolithic updates. While there may be debates about specific development and deployment methodologies, there is no debate on this. Integrating user feedback is too critical of a factor in today’s climate.

If you want to examine how your organization can begin the process of moving to Continuous Delivery, you may want to consider a DevOps Maturity Assessement.