When you want to have continuous delivery any data schemas that you have must support multiple versions of your application at the same time (as you may have multiple version deployed when new versions are rolling out)In my specific case I have entities stored in Azure table storage. When I am making changes to my entities I am usually having to add properties (as removing or renaming them is a bad idea as old versions of the application will potentially break), but once a new version is completely rolled out I don't need the old versions properties anymore as all the servers out there are using the new version, which means in the next rollout I can remove some of the old properties.I'm wondering if this problem can be solved more easily by having partial classes for each version of the entity.  This ensures that one version will always be accumulative for a previous version (ie will never take anything away or change anything) but will allow delegation to an existing property if something just needs to be renamed.Once a version has been completely rolled out and the old version will never be needed then the partial classes could be consolidated into a single class again (and any unneeded properties removed). If you know that you are only going to have a couple of versions 'live' at anyone time then you could perhaps use a 'current' version and a 'vNext' version explicitly.I've not tried this as a solution yet but wondered if anyone else has tried an approach like this and has any feedback, or if anyone has thoughts on whether this is a good or bad idea?
Is using partial classes for supporting multiple versions of data entities for continuous delivery scenarios a bad idea?
design;azure;continuous delivery