Why is the ShadowDb required when building in TFS?
My understanding of the shadowDb is that it used by the dbSync tool to detect changes in the development database in relation to the scripts, in order to import them in.
I am setting up builds in TFS on prem, and I am running to errors with the shadowDb, which I can fix, but it lead me to question why the shadowDb is necessary for builds. My mental model of what was happening is that a sql package is created with all of the scripts that arent already in the migrationLog table of the target database. My best guess now is that it is simply used to verify the scripts will function correctly, but that is assuming the shadowdb matches exactly with the target db.
Can someone help me understand this better?
Thanks!
I am setting up builds in TFS on prem, and I am running to errors with the shadowDb, which I can fix, but it lead me to question why the shadowDb is necessary for builds. My mental model of what was happening is that a sql package is created with all of the scripts that arent already in the migrationLog table of the target database. My best guess now is that it is simply used to verify the scripts will function correctly, but that is assuming the shadowdb matches exactly with the target db.
Can someone help me understand this better?
Thanks!
Tagged:
Answers
Thanks for joining and for your post.
You can find more information on this in the link below from our Readyroll documentation pages.
https://documentation.red-gate.com/rr1/key-concepts/target-and-shadow-databases
Kind regards
Redgate Software