The art of adhering to the continuous deployment model is to decompose features into very thin vertical slices that can fit into a small release cycle.
Online giants such as Amazon, Facebook and Google have adopted a model of continuous development and deployment. These companies are able to continuously improve their products, primarily online websites, by refining them on a continuous basis. Facebook is able to update its website, which is used by more than 1 billion people, twice a day.
This world of shipping early and often is alien to traditional enterprise software, which still adheres to a multiyear cadence in terms of planning and establishing a release date. At Qumulo, we saw this as an opportunity. We wanted to provide enterprise-grade software and deliver it at the speed of online companies.
In doing so, we aimed to build a reliable enterprise-grade file system that is released every two weeks. The reasons for doing so were obvious: We wanted to continuously provide our customers with value in the form of new features. We also wanted to quickly adapt to customer and market needs, which we can react to in weeks instead of years. And lastly, this model of continuous deployment provided us with a very quick time to market for our product.
Releasing software often in and of itself is of little value unless customers use and deploy it. Online companies have complete control over how (and when) they upgrade their infrastructure, both the hardware and software. Most software companies do not have that luxury. If you’re like us, you rely on your customers to update their infrastructure with the latest software. As such, one key metric we track is the fleet age, which measures the recency of software releases used by our customers.
Over the past five years, we have seen that 80% of our customers run a build that is about a month old. Adhering to a model of continuous deployment is easier said than done, especially for enterprise software that is deployed on-site. We have learned many lessons from this model, which are summarized below.
Testing Is Key
It goes without saying that the ability to continuously release software is predicated on quality. Our product is used in mission-critical applications with no room for error. As such, we test often and across all levels of the product.
Any new code is first subjected to a “sniff test” comprised of thousands of low-level tests to validate its quality. The new code will be rejected if a single test fails. Once the code is accepted and introduced to our revision control system, it will be continuously deployed and validated in our build system. Again, any failures at this stage can be immediately triaged and fixed.
This model of a continuous build system — coupled with testing across all levels of the product — allows us to ship that version of the software at any time. We do not have to spend time and energy to make our release candidate shippable; all of the builds are shippable by default. We are also big fans of “dog-fooding” our own product: Qumulo is Qumulo’s No. 1 customer. We run every piece of infrastructure on Qumulo and upgrade to the latest build before our customers ever do.
If you are asking your customers to upgrade their infrastructure every two weeks, the process better be painless and error free. Our upgrade process is incredibly simple and takes one-to-two minutes to complete.
Think Incrementally
It is fair to assume that most features will not fit into a two-week release cycle. This is especially true for complex enterprise features, which require many months to complete. The art of adhering to the continuous deployment model is to decompose features into very thin vertical slices that can fit into a small release cycle. Decomposing features into thin vertical slices allows us to ship early and ship often, even if the feature is far from complete. This model of creating thin vertical slices will help your customers use and interact with features of your product at a very early stage, which helps provide invaluable feedback. It should also expedite your time to market. You would be surprised at the number of customers who will use your feature much earlier than when you deem it to be “complete”.
Don’t Over Plan
One of the main benefits of this model is adaptability to customer and market needs. We can respond to these needs in a matter of months instead of years. However, doing so requires us to be adaptable in our planning process. As such, it’s important not to plan much in terms of what features you are building beyond of a six-month horizon. Be sure to also continuously revisit your plans to ensure that you’re working on the most important features to deploy what customers want.
This article originally appeared in Forbes as part of the Forbes Technology Council series.
Learn more
Qumulo Software Use Guidelines
5 Steps to a Successful Cloud Migration
From Mom-and-Pop to global reach: 4X storage boost delivers
The Art of Simplicity – Driving Customer Success with Simplified File Data Solutions
Contact us
Take a test drive. Demo Qumulo in our new, interactive Hands-On Labs or request a free trial.
Subscribe to the Qumulo blog for customer stories, technical insights, industry trends and product news.
