Questions on how 360Deploy handles certain things

[oilcan]

I'm very interested in this product but would like to know about how it handles certain scenarios.

• How does the solution deal with ESS shadow tables?
• What happens with custom value lists? Do they programmatically update as well if the production copy gets new entries?
• How does 360Deploy handle field name changes?
• I noted the documentation seems to imply field deletions are a bit of a problem - you need to remember to delete the fields in both the production and dev copy. Are there any future updates in which this might be handled more gracefully? Or is this just a limitation of what can and can't be handled via this method?
• We have a pretty massive production file, 15+GB. The size is mostly due to container data, 14+GB. I assume this would take a while to import, but will there be any difference in import speed for this database if the containers are stored internally versus externally?

Thanks.

[ryan360Works]

• How does the solution deal with ESS shadow tables? ESS shadow tables will be skipped
• What happens with custom value lists? Do they programmatically update as well if the production copy gets new entries? If you make changes to a custom value list on the production side and then do an import, the changes will not carry over. This is because Deploy creates an empty clone of the development file and then imports records from the current production file into the clone but does not import value lists so changes to value lists that only exist in the production will not be carried over into the new production file.
• How does 360Deploy handle field name changes? Changing field and table names will require you to recopy the script steps
• I noted the documentation seems to imply field deletions are a bit of a problem - you need to remember to delete the fields in both the production and dev copy. Are there any future updates in which this might be handled more gracefully? Or is this just a limitation of what can and can't be handled via this method? We can speak on how future versions will handle this right now but the reason that you need to delete the field on both sides is because the import is an ordered list. For example if you have fields A,B,C,D in both dev and prod files and then you delete field C in one file then A will go to A, B will go to B but then C will go to D. 
• We have a pretty massive production file, 15+GB. The size is mostly due to container data, 14+GB. I assume this would take a while to import, but will there be any difference in import speed for this database if the containers are stored internally versus externally? The import will take significantly less time with externally stored container fields.

[oilcan]

awesome, thanks so much for your answers!