Redgate随TeamCity变化( AutoDeploy的替代方案？)

Question

我正在使用TeamCity为我们的测试环境创建CI和.NET应用程序的自动部署(使用SVN进行源代码控制)，一切都很顺利。我正处于想要自动执行db脚本的阶段。我做了一些搜索并阅读了几篇文章，比如http://www.troyhunt.com/2011/02/automated-database-releases-with.html (troyhunt的博客非常有价值！)，许多文章似乎都指向使用RedGate软件来管理和部署更改。我有点担心让一个新的工具来处理脚本生成，所以我想知道是否有其他被接受的方法值得研究。

我们当前的解决方案设计标准包括一个项目，其中包含与数据库相关的文件，如orm db。它还包含一系列文件夹，其中包含我们的更改脚本，如下所示。

MySolution
 > MySolution.Data
    > 3.0 Scripts
       * 01 - UpdateUserTable.sql
       * 02 - UpdateRoleTable.sql
    > 3.1 Scripts
       * 01 - CreateJobTable.sql
       * 02 - InsertJobTypes.sql
       * 03 - AndSoOn.sql

我相信这种结构很重要，因为虽然我们希望在签入时自动部署到我们的测试环境中，但我们部署实际版本的频率要低得多，而且我不确定RedGate的比较工具是否能够处理有时发生的更改级别。这就是为什么我更喜欢使用脚本的版本文件夹，然后在发布时递增次要文件夹，以保持脚本版本的整洁。

有了这个预先存在的结构，我倾向于保留它，并添加一个TeamCity构建定义，它可以在成功部署时应用数据库脚本。我想我可以让TeamCity在预期的路径中识别新添加到SVN中的.sql文件，然后在服务器上执行这些文件，但可能我期望的太多了。在过去，我已经使用TFS和MSBUILD以及自定义构建步骤实现过这种解决方案，但对于TeamCity方式来说，我完全是个新手。

是否已经有了实现这样的目标的过程？对我来说，这似乎是一个相当正常的实现，我只是还不能弄清楚是如何实现的。或者，RedGate解决方案是我们应该追求的标准吗？

Answer 1

我在两年前读过同样的特洛伊猎人的文章。这是一个启示，我很快就让我们使用SQL Source Control + SQL Compare + TC启动并运行。这是一个很好的解决方案，但是有一些东西并不像我想要的那样工作。其中最主要的是SQL源代码管理没有(或没有)很好地使用分支/合并策略。此外，SQL源代码控制是一个带外过程，需要开发人员的培训、采用和对其怪癖的认识。它从未生根发芽。我们的团队最终离开了RedGate，转而支持TeamCity驱动的实体框架迁移，并且我们没有回头看。

对于您直接提出的问题:我认为您在这里尝试做的事情是可能的，尽管我认为寻找新添加的SQL脚本不一定是TeamCity的工作。Red Gate和Entity Framework都识别数据库本身中最近部署的脚本/迁移，并在确定应在何处开始应用更改时引用该脚本/迁移。您可以将类似的值('3.0')存储在数据库中，或者作为TC构建参数，然后使用powershell迭代较新的文件夹，并使用sqlcmd应用最新的脚本。

不过，您可能会考虑考虑基于EF的迁移，特别是如果您已经采用了代码优先模型。如果你感兴趣，我可以更新这个答案来更多地讨论我们是如何做到这一点的。

更新：

EF代码优先迁移通过捕获迁移类中的一组离散的DB架构更改来工作。这个类有一个Up和一个Down方法，可以应用/撤销这批特定的模式更改。这或多或少等同于Ruby和其他人的做法。

当您对实体模型进行更改(添加表、删除列、更改约束等)时，您可以通过在Package Manager控制台中调用Add-Migration <DescriptionOfSchemaChange>来创建一个新的迁移类。这将生成一个名为<timestamp>_<DescriptionOfSchemaChange>.cs的新类。然后，您可以通过调用Update-Database在本地应用该迁移。实体框架为您管理细节，但您可以根据需要在迁移步骤中注入任意SQL。PluralSight提供了一个涵盖这些概念的great course。

迁移由可执行文件migrate.exe管理，该文件作为实体框架NuGet包的一部分进行部署。在TeamCity中，您可以使用migrate.exe对指定的数据库运行迁移。首先，必须将migrate.exe本地复制到包含迁移类的程序集。然后，只需使用DB连接字符串作为参数对该程序集运行migrate.exe即可。工作目录是迁移程序集的工作目录。

copy ..\..\packages\EntityFramework.5.0.0\tools\migrate.exe .

migrate.exe ASSEMBLY.dll /connectionString="CONNECTION_STRING" /connectionProviderName="System.Data.SqlClient"

Answer 2

在对如何实现我的目标进行了大量的搜索和学习之后，我决定继续编写我自己的控制台应用程序来为我做这件事。我将在这里列出基本步骤，稍后可能会更详细地阐述它们。

DatabaseRevisionUpdater (控制台应用程序)

1. 使用SVNSharp，DatabaseRevisionUpdater连接到我们的SVN服务器，从指定的SVN版本范围将SQL脚本文件读取到内存中。
2. 在.NET中创建事务，然后应用程序逐个读取脚本文件。如果在运行这些脚本时遇到任何错误，事务将回滚，应用程序将退出，错误代码为-1。
3. 目标数据库应包含一些新的日志表，在进行更新时会写入这些表。版本表跟踪进行了哪些修订、成功和失败。一个单独的表包含有关为此修订请求运行的每个脚本的信息(状态分别为成功、失败和已跳过)。
4. 将来进行更新时，将根据步骤3中的表确定数据库的版本。如果该请求与以前的任何成功更新相交，则更新将不会继续进行，因为它假定已应用了该更新。也可以从这些表格中确定SVN更新版本。

TeamCity集成

• 添加了一个运行器类型的构建步骤：
• 工作目录是包含我的控制台应用程序的构建服务器上的目录
• 运行:自定义脚本(不要使用带有参数的可执行文件，因为它似乎不能处理包含双引号的参数，就像我的dbConnectionString)
• Custom脚本:可执行文件后面跟着针对我的数据库的参数。参数包括svnUsername、svnPassword、svnPath、databaseConnectionString，最重要的是RevisionTo。我使用%build.vcs.number.APP_ID%来获取当前版本的修订号。

奖励用法-更新断开连接的数据库

这一切都适用于我们的测试环境，但我们的实时环境位于一个隔离的网络上，该网络无法访问svn或internet (出于安全原因)。对于我的控制台应用程序，我使用了几种不同的模式。上面描述的模式是直接更新，这是一个一体化的解决方案。它通过查看其日志表来确定数据库的当前版本，它轮询SVN中的所有更新，直到您指定的版本，它会在目标数据库上运行这些更新，并相应地更新其日志表。对于我们的实时环境，我添加了几个额外的模式。导出和导入。

• 导出功能用于获取某个版本范围内的SVN脚本。然后将它们保存到一个XML文件中。它根本不关心目标数据库。XML导入用于导入

数据文件，并将其中的更新应用于目标数据库。它关心的是版本兼容性，但与SVN无关。

这基本上就是我的解决方案。没有任何开箱即用的东西，但它的效果就像一个护身符。我可以让TeamCity很好地与它交互，并使用控制台输出详细地描述该过程，使其尽可能透明。TeamCity在其构建日志中报告所有这些输出，并且根据我的返回代码是0还是其他值，也会失败或成功。

经过一周的旅程，我决定写一篇简短的博客文章，详细介绍我是如何来到这里的，以防其他人感兴趣：https://andrekriegler.wordpress.com/2013/09/12/auto-deploy-database/

Answer 3

在Red Gate，我们目前正在做我们称之为"migrations v2“的工作。这是一种数据库部署技术，它既使用模式比较方法，也允许用户指定自己的脚本，例如在数据移动的情况下。

除了a GoogleGroup forum，还有一个series of web pages更好地描述了这一点。

如果您对此功能有任何疑问，请告诉我。