Multiple Concurrent Versions

Multiple Concurrent Versions is the term I use to describe a practice for deploying multiple versions of a web app at the same time. Technically, the concept applies to any kind of deployment bundle, but Java web apps make a good example.

Here are the basic precepts of the practice:

1. We assume that the thing being deployed, the deployment bundle, is represented as files and folders.
2. Physically moving the deployment bundle to the deployment target (the runtime environment) is a distinct step from activating a particular version.
3. The deployment target will, at any given time, contain multiple versions of the same deployment bundle: 
• old versions that used to be in production 
• old versions that never made it to production 
• the current production version 
• future versions that are very close to production ready
4. Multiple versions are concurrently deployed and accessible at the same time via version specific urls:
   
   http://v8.mycompany.com/myapp
   http://v9.mycompany.com/myapp
   
   The current or default version can be accessed via a version independent url:
   
   http://mycompany.com/myapp
5. Activation is the process of marking a particular version as the default version. 
• Changing the default version from an older to a newer version is called a rollout. 
• Changing the default version from a newer to an older version is called a rollback.
6. Each deployment bundle version should have a cryptographic identity (i.e. sha).
7. Concurrent versions should be isolated. That is, a bug in version 8 shouldn't be able to kill version 7.