Using sandboxes to migrate data changes from dev to prod
Posted: Wed Jun 21, 2017 2:12 am
Has anyone tried using sandboxes to help with dev to prod migration of data changes? I tried it our this morning and it seems to work quite well. It would also solve quite a few issues caused by forgetting about some configuration changes done within cubes in a dev environment which don't make it to production. It could be also used to help merge separate streams of development where developers are unaware that others may have changed configuration data which overlaps with their own work as every developer can have a separate sandbox.
The basic steps:
1. Ensure all configuration work on dev is done in a named sandbox.
2. Do a savedata to comit sandbox changes to the cub_delta files.
3. Copy user\}sandboxes\? (find the correct sandbox number from the namemap file).
4. place user\}sandboxes\? in production.
5. update namemap file on prod to reference new sandbox folder.
6. start prod server.
After the above steps, the data changes performed in dev are available in the same sandbox in prod and can be fully reviewed before committing and updating the base data.
Seems to me this would be a pretty safe, controlled, rollback-able way of promoting relevant data changes to production. You could easily leave off cub_delta files which you know are not needed, and you would get the chance to check the result in the sandbox before committing.
Combine this with Git (for text object change tracking (rux,pro,cho,sub, etc)) and winmerge and it would be a pretty complete and robust way of managing development.
Interested to hear any thoughts. Have I missed something which means this shouldn't be done like this or did I miss the memo and everyone is already doing this?
The basic steps:
1. Ensure all configuration work on dev is done in a named sandbox.
2. Do a savedata to comit sandbox changes to the cub_delta files.
3. Copy user\}sandboxes\? (find the correct sandbox number from the namemap file).
4. place user\}sandboxes\? in production.
5. update namemap file on prod to reference new sandbox folder.
6. start prod server.
After the above steps, the data changes performed in dev are available in the same sandbox in prod and can be fully reviewed before committing and updating the base data.
Seems to me this would be a pretty safe, controlled, rollback-able way of promoting relevant data changes to production. You could easily leave off cub_delta files which you know are not needed, and you would get the chance to check the result in the sandbox before committing.
Combine this with Git (for text object change tracking (rux,pro,cho,sub, etc)) and winmerge and it would be a pretty complete and robust way of managing development.
Interested to hear any thoughts. Have I missed something which means this shouldn't be done like this or did I miss the memo and everyone is already doing this?