The servers are upgraded without notice. You can then later "upgrade" each database, that continues to run in the same compatibility level as when created.
@ypercubeᵀᴹ We're using RedGate SQL Compare with a license for the automation of it.
I'm not exactly happy with it, but with the auditing and other rules at my company, it's all we get.
We've been using the Compare thing as a build tool for a long time, but starting a week or two ago we have a new rule: No one, ever, runs a script in prod manually.
It's been interesting. Some real gotchas in there.
Like, let's say you roll out version 1.0. Then you roll out 2.0 but it has a problem. You can't re-deploy 1.0 because it doesn't have the knowledge of how to revert the custom data changes you made as part of the 2.0 rollout script.
You have to craft a special 2.0-to-1.0 rollback script that reverses those changes.
Was simply curious what others are using and how well they work.
@ypercubeᵀᴹ The rollback script isn't for a failure of the script itself--it's after the transaction is committed. Like, the next day when you discover that you did something Real Bad (much worse than simply "really bad").
@ypercubeᵀᴹ Right, I may have used a term that was misleading. At work they call it a rollback script, but that's distinct from a transaction rollback.
Sometimes changes are just impossible to be done in reverse. Say, you change a column from text to binary. Existing values are converted. Then new (binary) values are inserted. If you try to change the type back to text, some of the new values fail the conversion.
lol, I was. Now I'm at home waiting for some people to come by for drinks. Just thought I'd help someone out with an answer, even if it is 4 months late!