Had a discussion with a colleague about the best way to setup uSync on a prod site with a staging slot.
Having the two slots sharing a db means running uSync on startup will mess up prod while the staging slot warms up and runs the import, however having two separate db connections is problematic with having to replicate content between them and staying in sync.
I am curious what you all are doing for similar setups?
I do exactly as you described but with a zero rename / delete policy.
To remove properties I first mark them as deprecated (in the notes) and then wait a release or two before they are removed.
That way usync can run in the release slot - the DB is updated but nothing is removed if live / prod restarts. If it does no matter - all the generated models will continue to find the properties they need.
Sounds hacky I guess but it works.
Hmm - remember this is v13 where Umbraco is less “chatty” with the DB - effectively everything CMS structure wise is loaded on startup so a prod slot won’t really need to access the db tables whilst usync is running.
Now I think about it I’m keen to hear of any 15,16,17 devs on what they do with this and if there are new challenges.
We thought about this as well and the conclusion is that you don’t want any breaking changes in your database. So the best course of action in my opinion is go with @cheeseytoastie suggestion. And only when you do breaking releases, you can clean up and do breaking changes, but in that case, just don’t to a swap with the slot, but a full release.
USync only runs on the scheduled publisher.. and you should only have one of those.. so I think this setup isn’t supported anyway from Umbraco.. eg having two scheduling publishers running against the same DB. (also think if UAT is an umbraco upgrade too would seriously break things too)
Sharing a DB should only be in a loadbalanced env.. when multiple subscribers can run alongside a single Scheduling Publisher (aka backoffice)
USync complete with it’s sync content between two environments (with separate db’s) would be the recommendation?
Or if you don’t want to go all in.. then you can have UAT monitoring for ContentChanges via uSync Standard (again against a separate DB) when the slots change and the DB connection changes then the content changes would also be processed. But the problem you have then is that if any changes had occured to the same content on production whilst you are developing, then UAT usync content processing would revert them.
We have almost all our sites in a slot swap setup and we always apply the uSync updates manually. This means that we have to code defensively to ensure that values from fields which aren’t yet published yet don’t cause null reference exceptions, but this is just good practice anyway.
We also have a non-destructive policy, so a release will only include additions. When we want to perform deletions we batch them up into a single release that only contains these.
Occasionally with a bigger release, we will duplicate the database and point the slots at the separate DBs so that we can roll back if needed once the uSync changes have been applied.