Basically, I have two same feature classes (A & B) both in enterprise geodatabases. Let's say A is in development environment and B is in production environment. Now, I have applied some structure changes (added new field, applied some field length changes, etc) to A manually via ArcGIS Pro. My goal is to deploy the same changes to B via scripting in production environment.
Can this be done via python scripting? I tried Feature Compare tool without much success as it would only list the deltas or diferences in two FC. Is there a GP tool or ArcPy fuction that I can use to extract the deltas between A and B and apply them to B.
I assume that this can be done at the backend via RDBMS tools but wanted to avoid using this due unknown risks.
I've not had to actually do this process, but it sounds like Export XML Workspace Document and the corresponding Import tool might be helpful to you if you use the schema only option. And it is doable with Python.
You might want to test it on a throwaway table first, just to be sure that when you combine overwriting the target and schema only that you don't end up with an empty output. Esri has an extensive whitepaper on the XML format, though I can't find this particular aspect specifically addressed.
Thanks, Josh! I will check the white paper.
I also feel that this workflow is achievable with python. My concern is that I am not finding any out of box GP tools in Pro under data management toolbox or GDB admin toolbox. Therefore, I think I will have to build a logic in python with my basic to intermediate python skills.
I am also curious how others government organizations are applying structure changes on their live or production environment. Can't imagine this is all manual via using GUI tools from Pro?
I think you can do it by creating classes to represent the dev table and its corresponding prod table with the instantiation methods setup to get the all the schema properties you want to compare. Then you can compare the two class's (tables) list of fields, or dictionaries of fields and their properties, for differences. Then trigger modifying the production environment changes if triggers. The XML route may be simpler and less taxing on the cpu, but I can't comment on that as I haven't delved that deep.
I think that most shops manually update the production environment once they verify the development schema/data is working, to ensure that the changes made are exact. Just something to consider, what if your script fails mid way through updating production, leaving your production environment corrupted and down until it is fixed?