Continuous delivery is nothing new. The term was popularized by Jez Humble and David Farley back in 2010.[1] What’s changing today is how broadly investment banks are beginning to apply the concept aiming to reduce the risk, time and cost associated with software development and deployment on their trading platforms.

What is continuous delivery?

Humble describes continuous delivery as “the ability to get changes of all types—including new features, configuration changes, bug fixes and experiments—into production, or into the hands of users, safely and quickly in a sustainable way.”[2] Whether you are deploying a large-scale distributed system, an embedded system or an app, the goal is to transform what was once a difficult task into a routine and predictable process that you can perform on demand.

It’s a radical departure from the typical approach, whereby firms seek to minimize risk by developing software outside the production environment and conducting multiple rounds of testing before going live. The fact that the process has become so cumbersome is not surprising: technology is complex and full of interdependencies. One does not have to look far to find harrowing examples of seemingly minor deployments causing unintended and sometimes widespread disruption. But, as Humble says, “If it hurts, do it more often and bring the pain forward.”

 What makes capital markets a good fit for continuous delivery?

Although the complexity of capital markets and capital market solutions really poses challenges for the successful execution of a continuous delivery strategy, the potential upside is significant. Done properly in the context of a trading platform like Murex, continuous delivery could help reduce costs and time to market, improve job satisfaction, and increase the quality of both implementation and support.

How can you achieve continuous delivery?

According to Humble, achieving continuous delivery requires the elimination of code freezes and the traditional integration, testing and hardening phases that typically follow “dev complete” status. Code should always be in a “ready to deploy” state—even when there are many hands working behind the scenes, even when it’s changing every day.

To reach that state, you’ll need to focus on:

  • Configuration management. Your application environment must be reproducible and traceable. You need to know exactly which version of software, data and infrastructure you are working on at any given time.
  • Continuous integration. You must be capable of continually integrating new software branches and/or data into the “mainline” or trunk version.
  • Continuous testing. You must get in the habit of continually validating changes by running tests—automated, where possible—throughout the delivery process.

So what’s holding firms back? Join me next time for a discussion of the key challenges associated with continuous delivery in general and in a Murex environment in particular.

If you would like to discuss this topic further or get additional information, please email


[1] Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation, Jez Humble and David Farley, Pearson Education (2010).

[2], Jez Humble, copyright 2010–2016.