Multi-versioning

From Pearl Language
Jump to navigation Jump to search

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.