What we all end up with are either DB migration steps (a-la Rails migrations), of which I approve see, or schema comparison tools (a-la vsdbcmd.exe) of which I'm very skeptical after being burned several times on large DBs (they are as good as the tool, and some tools are better, still I find explicit migrations much better).Īs a side note, My startup is recording all DB schema changes, like a DB flight-recorder of sorts, and one of my future goals is to add capability to generate compensating actions for any DB schema change and thus be able to revert the DB schema to any previous state (by simply rolling back every change, in reverse order). Having witnessed DB upgrades at MS Azure scale (see ), and having to code myself several SQL DB upgrade steps (internal system upgrades, the kind done when you install new DB engine, not user upgrades) I can say with confidence that DB upgrades are hard. If you're really unlucky, this may involve a size-of-data transformation (eg. DB upgrades, on the other hand, must take existing state (which can measure GBs and TBs) and transform it into a new state. Either way, the ways ways in which it can go wrong are few (at least compared to DB upgrades). It can do so by deploying to a new location and then redirecting the entry points, or it can do so by laying over the new code. Code deployment only needs to ensure that the new code is in place.
There is a fundamental difference between code deployment and DB upgrades: DB upgrades must preserve (and upgrade) the existing state.
0 kommentar(er)
