Release Engineering as Force Multiplier
Data storage is a mission-critical component of any company’s IT infrastructure, with even minor system changes able to bring the house down on service availability and inflict a disastrous impact on the business. The recent Amazon’s S3 outage is just the most recent overt example, for instance, of how destructive a service outage can be.
At Scality, we believe that a well-architected, feature-rich product is the key to breaking through in the still-nascent Software Defined Storage market. We also believe, however, that with regard to infrastructure software, tools and engineering practices are at least equally important. In short, “how we build” is inherent to the success of “what we build.”
Share on Twitter: “We believe that a well-architected, feature-rich product is the key to breaking through…”
Eighteen months ago, Scality decided to initiate a cultural change, transitioning from the classic “waterfall” software development process to a more “agile” one. We introduced “tech-train” releases to allow for frequent new feature delivery, in addition to our standard “long-term-support” bug-fix-only releases. In conjunction, our Product management team worked hand-in-hand with our customers to split feature requests into more manageable pieces that could be delivered in an iterative fashion.
We set up KPIs and transitioned into a data-driven engineering organization, displaying our performance metrics in our company offices. Then, with the vision securely in place, Scality assembled a Release Engineering team to streamline and industrialize the release process.
Release Engineering is an engineering discipline which focuses on optimizing the company’s ability to ship quality software at a fast, constant pace. At Scality, this boils down to building, maintaining, and growing an automated continuous delivery pipeline, intended to transform source code contributions into a product that is integrated, compiled, packaged, tested, and signed in a timely manner. A product ready for release. We have built and open-sourced a toolset that we have presented at RelEng’16 ACM conference at Seattle and at regular company’s meetups.
Scality’s continuous delivery pipeline offers a strong quality guarantee to our customers, ensuring that all changes — major, minor, incremental — pass through the same constantly-improving automated validation process. And the pipeline is even more useful to Scality’s development team, offering:
- A safety net, to embolden developers in creating new feature
- Substantial time savings (the pipeline offers a less-than-50 minutes fast feedback loop)
- A reliable collaboration framework
- Empowerment (developers no longer require outside personnel to complete their work before shipping their features)
The title of this post, “Release Engineering as Force Multiplier” is borrowed from John O’Duinn, Director of Release Engineering at Mozilla. In O’Dunn’s talk, he explains how the relatively “small” Mozilla relies heavily on tooling to effectively compete with such web giants as Google, Apple and Microsoft. Scality is in a similar situation as Mozilla in many ways, firmly established in the Leaders zone of Gartner’s Magic Quadrant, a David amongst such Goliaths as Dell/EMC and IBM/Cleversafe. Scality excels due to our top-notch development team, yes, but also because our team is supplied with the tools and the environment necessary to make the foremost impact.
Less than a year into Scality’s cultural transformation, the continuous delivery system we put in place served to greatly improve our release predictability. On-time delivery became the rule rather than the exception, and the number of feature deliveries jumped from 5 in 2015 to 51 in 2016. As a final measure, Scality RING’s average feature time-to-market has dropped from over a year to just four months (definitively illustrated by the company’s delivery of four full “Tech Train” releases since September, versus 2015’s lone release of RING 5.1).
Author: Rayene Ben Rayama