The goal seems to be:
- Allow for the new version for a subset of users (great for agile work flow)
- avoid data loss or unique key loss/duplication since both versions run concurrently
I am in a similar environment, and I can't seem to find a documented development life cycle that allows for the above. I would say it is a cross between A/B Testing and "Canary Release Strategy".
We solved this with a fourth environment, between testing and production (we call it beta even though it is actually production):
- alpha developer testing. This is where developers push branches and merge code.
- QA/staging user testing. This will be identical to production once new version is released.)
- beta production for a subset of users. (we are trying to come up with a better name since having production data on "beta" makes auditors nervous.. I'm not sure if "canary" will fly... no pun intended.
- www (Generally Available production)
Show stoppers should never make it to beta (in this context) since it is production, which is separate from staging/QA.
If you like this answer, maybe you can name the release cycle or deployment strategy after me :)