Question

我们多年来一直在使用颠覆，但现在正在变得善变。

我们有一个使用teamcity和脚本的漂亮的自动数据库版本控制系统。（它的.net和msbuild以及powershell，但那是无关紧要的）。 ]

我们有一个数据库目录：

/database/
/database/functions
/database/migration
/database/storedprocedures
/database/views

migration文件夹包含DDL和数据修改内容。

源/构建系统的工作原理如下：

开发人员对存储过程进行了更改
开发人员提交更改为svn
Teamcity检出代码并构建
数据库迁移生成脚本运行获取启动构建的svn修订
脚本在最后一个已知修订版本和此修订版本之间的数据库目录中执行diff。对于diff中的所有文件，它将它们连接到文件名为％buildnumber％_％revision％.sql
脚本放置最终的更新数据库信息setversion =＆＃39;％buildnumber％＆＃39;进入领域
然后脚本将此新文件提交回subversion
build已打包

然后在发布时或开发时，按顺序运行SQL迁移文件的问题是，数据库升级和迁移。

这是一个很好的系统，因为这意味着你做你的工作并且不必担心编写迁移，或者注意你的更改，不会对测试环境感到抱歉，我忘记了编写该存储过程的迁移，等待30分钟，然后我将为您提供一个新版本＆＃34;

然而，随着向mercurial的转变，步骤7. Script then commits this new file back into subversion不能很好地运作。

使用subversion并不是什么大不了的事，因为你只是回到一个永远不会在构建系统之外被修改的数据库目录。

对于mercurial（我在这里有点新手），我们需要提交并推送需要进行拉取和更新的更改。我可以让这个工作没有问题，但它的代价是将源处于无效状态，它只是感觉好像做错了。

我想在mercurial中使用提交/预提交挂钩，但是后来我们丢失了构建版本版本并且在找到命名约定时给自己买了一个问题来对数据库进行版本化，然后再次工作当我们有一个分支时。

我想知道其他人在做什么呢？

Answer 1

如果您的自动更改是：

拉动并更新
在目录中创建新文件
将新文件提交到存储库
推

那么你冒险做的事情就是你需要额外的头脑。在您撤离的时候，其他人可能已经推动了一个新的头（在旧的头顶上），您的本地存储库（在构建服务器上）不知道。

这就是错误。如果你没有修改现有文件，那么这里不会发生合并冲突，因为你只是在现有的变更集之上提交，所以构建服务器根本不会合并。

即。时间方面，这将是会发生的事情。这是当前的主存储库时间轴：

1---2---3---4---5

你拉，然后把它带到你的构建服务器。然后使用更改创建一个新文件，并提交，形成此时间轴：

1---2---3---4---5---6

与此同时，另一位开发人员也将一个新的变更集推送到主存储库，所以当你推送时，你会得到这个：

1---2---3---4---5---6
                 \
                  \-7

（6或7是您的新变更集，另一个是来自其他开发人员）。

这是可能发生的最糟糕的事情。您可以尝试在构建服务器上进行自动缓存。同样，这不应该产生合并冲突。

Answer 2

它的价值。我最后用一个mercurial commit hook做了这个。

因为我们正在使用Windows＆amp;的powershell。

我把它放在hgrc

中

[hooks]
commit.MigrateDatabase=powershell -File ".\BuildAndDeploy\DatabaseMigration_HgHook.ps1"

在powershell文件中，简要介绍

$ hg_node =（gci -Path env：hg_node）.Value $ hgCommandLine =＆＃34; hg status --change $ hg_node＆gt; \ Migration.Working \ ModifiedFiles.txt＆＃34; Invoke-Expression $ hgCommandLIne

然后解析ModifiedFiles.txt以获取任何已添加或修改的文件，将它们连接到另一个文件中，并根据版本和日期的组合对其进行版本化。

自动数据库版本控制和Mercurial（可能还有git）

2 个答案: