Multi-versioning

multi-versioning opens up some amazing business capabilities, like:

• gentle/gradual release of high risk or experimental features;
• running product experiments on 1% of the live user base to prove costly assumptions;
• offering early access to premium customers;
• hot-fixing and preventing problems much cheaper than before; and
• running marketing initiatives around marketing events rather than technical deployment capabilities.

Gojko Adzic:

Being able to run multiple versions of different components that talk to various versions of other components is a pretty good solution or the problem I outlined above -- having some version of the deployed software visible to a subset of users, where other users see a different version. I’m NOT talking about web re-routing or feature toggling here -- but about a systematic solution where multiple versions can run in parallel, without interruption. When that’s solved, there is no need to interrupt sessions or work for a deployment any more -- people can just keep using the current version until they finish the session. It’s also possible to release things gradually -- in the Paypal dashboard example, they could have just released the dashboard to customers having a single currency account, and solve the whole UX consistency/iterative delivery problem. This also allows deployment to be decoupled from releasing. Which is why multi-versioning is so powerful as an architectural concept.

At the same time, multi-versioning opens up some amazing business capabilities, such as gentle/gradual release of high risk or experimental features, running product experiments on 1% of the live user base to prove costly assumptions, offering early access to premium customers, hot-fixing and preventing problems much cheaper than before, running marketing initiatives around marketing events rather than technical deployment capabilities.