3

我正在努力跟上数据库更改以及如何干净地维护和部署从 Dev 到 PRD 的数据库更改，从一个版本到另一个版本。

目前，我使用 SQL 脚本来确定自上次发布以来发生了什么变化；

  • Procs 和 Views 更容易推进，因为我可以简单地删除并重新创建（如果存在）。
  • 表更改更加困难，因为不能简单地删除现有表。

但我认为我无法理解的主要问题是，我们在任何两个主要 PRD 版本之间都有多个针对 Dev 和 UAT 的迷你版本。

开发和 UAT 迷你版本还可以，因为我从其他开发人员那里获得了更改列表，我将其与我的合并，然后发布，而且我是开发和 UAT 数据库的系统管理员，所以我确切知道那里有什么和当我应用更改时会发生什么。

对于 PRD，我必须准备一个干净的脚本并将其交给 DBA，以便他可以在那里运行它，但除了 PRD 上的表名、列和数据之外，我无法查看其他任何内容。

PRD 的这个脚本应该捕获几乎所有进入迷你版本的内容，但大多数时候这些迷你版本不是连续的，有时会相互否定，因为一个添加了功能 A，然后后续版本删除了功能 A，但对于 PRD，我们可能必须添加功能 A，因此无需进行第二个迷你版本，这将有效地删除功能 A。

所以简而言之，我正在寻找管理和跟踪版本之间的数据库更改的方法，以及为数据库更改构建部署脚本的好方法。

注意：我确实保留了一份手动维护的 TFS 中所有 SQL 对象的副本。

我尝试使用数据库项目，但我没有很幸运地实现了我想要的。

有什么想法吗？非常感谢任何帮助

4

2 回答 2

2

I'm not familiar with TFS, I used Git (CVS, and SVN previously), hence take this answer in perspective.

Managing and versioning the SQL bits have been the worst of my nightmares. there are some tools that easy the changes management, red-gate SQL Developer Bundle, which handles comparisons, and allows connection to versioning systems too. in a lesser measure for your request you have idera SQL comparison toolset, idera's perfectionist approach to everything shouldn't be over-viewed.

Anyway in my opinion managing changes can't and shouldn't be approached as a technical thing it has to be part of the IT governance, and procedural, it requires to document and communicate among any relevant functions.

When some mini-release, hot-fix, micro-change or similar stuff happens, they have to be reflected at every other environment that needs to get it.

Of course if there is a mini-release in production and you are the middle of a UAT, you might not want to insert the mini-release in that environment. IMO, soon after the UAT you should apply the mini-release to the environment and perform a E2E QA session in order to make sure that the environment is fine.

If you read my previous paragraph you might find some problems lets say that UAT has a SP version 4 and the mini-release the same SP is 2... how do you make sure that you are not causing regressions?

This is when version control systems and merging tools come to help. Red Gate tools should also help you building the deployments.

But, I believe that governance, communications and follow the rules are the most important factor for continuous success.

The tendency today is implementing continuous integration, and build testing environments on-demand, there are in-house, hosted and on the cloud. usually they are not cheap to build and to maintain, but they pay off!

Last but not least, a couple of same of rules that you should abide when developing for SQL deployments:

  1. Every change script should be repeatable, for example
    • before creating a procedure, check if it exists and delete it before the creation
    • before any insert check that the row doesn't exists and then insert else update
  2. when deploying to multiple databases, every change script must make sure that you USE the proper database (here I found that synonyms are one of the best inventions since the creation of the can opener)
  3. change scripts should follow a sequence. for each object:
    • DDL
    • apply the DCL for the DDL above
    • apply the DML for the table.
  4. I found that the best sequence in for scripts are
    • create/alter Tables
    • create/alter views
    • refresh all views
    • create/alter functions
    • create/alter functions
    • perform every DML.
  5. in every script avoid failing to the temptation of ordering the sub parts of the scripts by ABC, usually you have dependencies like FK or SP that execute other SP that make the ABC approach frustrating.
于 2013-07-05T12:46:42.007 回答
1

我知道迟到了，但试试redgate工具，它是控制数据库对象的源和同步的最佳工具。我一直在使用这个工具，并且对结果深信不疑。有许多选项可以将您的 SQL 脚本、用户、安全性、设置和特别是数据从一个数据库同步到另一个数据库。

于 2021-02-05T19:52:06.730 回答