Climbing Mountains Faster
Climbing Mountains Faster
Join the DZone community and get the full member experience.Join For Free
Continue to drive demand for API management solutions that address the entire API life cycle and bridge the gap to microservices adoption.
Originally authored by Ken Yagen
In a recent post, James outlined how MuleSoft is using Lean Startup principles to build Enterprise Software. We have been doing this for a while in our cloud platforms – CloudHub, Anypoint Service Registry and Dataloader.io; however, our core enterprise tools and products – Mule ESB, Mule Studio, Anypoint DataMapper, and Mule Management Console have always been on a much longer release cadence. Mule ESB Enterprise is the core platform on which many of our customers build hundreds if not thousands of services and integration processes on, so frequent releases and updates can be expensive for them to consume. Typically we release new Mule ESB enterprise versions every 9 months. As a hybrid product company with multiple products, we need to manage the demands of both the cloud and on-premise. Recently, we decided to make some changes to our development cycles and team orientation. We’re using names of famous mountain ranges for these new releases, the first is named Andes after the iconic mountain range in South America (relatively) close to our development labs in Buenos Aires, Argentina. The next is Big Horn, Cascade and then Dolomite.
The Value Stream
Most features that go into Mule are developed in 1-2 iterations of work (2-4 weeks). If you have ever studied value stream mapping in relation to software development then you know that a 9 month release cycle means that at best it takes 13 1/2 months for a feature to make it through the development pipeline and begin realizing value. That is a very low efficiency ratio (development time / time to release). On the Cloud side we have seen much higher efficiency ratio with one month releases and also quick feedback loops on how our products are doing. However, with our goal of providing a common toolchain and runtime across environments, these core components still experienced the lower efficiencies.
To improve on this we decided to enhance Mule Studio to support multiple runtimes and shift our entire engineering organization to a faster cadence. All software is now developed in two month cycles (some products like CloudHub still release monthly). At the end of the two months, software is released and made available to customers. This increases our efficiency by reducing the denominator in the equation.
These new releases are versioned as 3.5.0-X with the X representing the name of the release. This first release is 3.5.0-Andes and includes updates to CloudHub, Studio, Devkit, APIkit and Anypoint Service Registry.
The result is that we can now upgrade CloudHub with the new releases while still working towards a major on premises release of 3.5 next spring.
So if you are using CloudHub or considering it for your project, you will start seeing significant increases in capabilities at a much more rapid pace. We are rolling out many new capabilities around deploying SaaS integrations, designing and managing APIs, and supporting B2B partner integrations all delivered through CloudHub and the AnyPoint platform. For on premises deployments, the challenges are different – upgrading installations and supporting different product versions within the same customer environment is something we know our customers prefer to avoid. For this we still will offer our longer term Mule ESB Enterprise updates every nine months that have been thoroughly tested and certified for the variety of environments our customers choose to run in.
But on premises customers can realize the advantages this new model brings to the development of our Mule Studio tools and the cloud-managed Anypoint Service Registry and Anypoint API Manager. Two month updates to our development tooling are rolled out with backward-compatible support of our existing on-premises releases as well as CloudHub and many of the new Service Registry capabilities can enhance an existing Mule deployment with no changes or a registry agent update. We are also releasing a 3.4.1 maintenance update with bug fixes and security updates for Mule 3.4 and MMC.
For community users, check out the latest Studio download and install your 3.4 community runtime. As appropriate, future release cycles will include community milestones as well.
You may wonder how this affects the product documentation? The latest release documentation will always be available with a release with specific notes on pages that cover changes that are new since the last major on-premises release. A full 3.4.x documentation set is also always available.
This is part of an application of Lean Startup principles at MuleSoft. While focused on software releases, this process and cadence has been applied across MuleSoft as an organization in everything we do. Andes and the follow-on initiatives (Bighorn, Cascade, Dolomite) encompass how MuleSoft is delivering quickly and iteratively to respond to the needs of our customers, partners, and community.
Published at DZone with permission of Ross Mason , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.