SQL Server 数据库 :: 使用 Github 和 TeamCity 实现持续集成

引言

在我之前的 文章 中，我们已经了解了如何为 Microsoft SQL Server 数据库实现源控制系统。

在实现源控制系统之后，数据库项目维护的下一步是建立一个持续集成系统。您可能会想，既然已经有了版本控制系统，为什么还需要持续集成呢？

源控制/版本控制系统有助于管理项目源代码的变更集，并将它们保存在一个所有团队开发人员都可以访问的中心位置。而持续集成系统则有助于在源代码的每次更改后构建项目。这种每次更改后构建项目的方法有助于及早发现代码错误，并减少确定导致错误的具体更改所需的时间。因此，它提高了发布的质量。

市面上有许多流行的开源和付费持续集成工具，如 Buddy、Jenkins、TeamCity、GitLab CI 等，但作为本课程的一部分，我们将重点介绍如何使用 JetBrains TeamCity 设置持续集成系统。

必备组件

要开始这一步，您应该已经准备好数据库项目的源控制系统。如果您还没有，请参阅我之前写的文章。

• 使用 Github 实现 SQL Server 数据库源控制

如果您已经完成了，那就太好了。我们可以继续下一步。

2. 使用 Github 和 TeamCity 实现 SQL Server 数据库持续集成

a. 设置 TeamCity

要将 TeamCity 用于数据库项目的持续集成，您需要有一个正在运行的 TeamCity 服务器。理想情况下，您应该已经为您的 Web/移动应用程序项目设置了一个服务器，并且您也可以将该服务器用于数据库项目。如果您还没有，则必须设置一个服务器。

您可以从 JetBrains 网站登录使用 TeamCity 的云版本，或者如果您想在自己的服务器上设置 TeamCity，则必须从 JetBrains 的 网站 下载并安装 TeamCity 服务器和构建代理。

TeamCity 服务器和构建代理的下载、安装和设置都很简单。本教程的范围不涵盖详细的解释，但互联网上提供了许多分步教程。事实上，官方网站本身也提供了全面的文档。链接如下：链接。您可以使用默认的安装设置和默认端口。

请按照网站上的说明进行操作，您的浏览器应该会显示以下屏幕

您应该会看到服务器已启动并正在运行，并且有一个代理已连接。点击“创建项目”按钮将您的数据库项目添加到 TeamCity。

b. 在 TeamCity 中创建新项目

在下一页，我们可以看到有手动创建项目的选项，也可以连接现有的远程存储库并从中创建项目。根据我们的目标，由于我们的数据库项目在 Github 上，我们需要选择从远程存储库创建项目的选项。

将您的 Github 存储库链接粘贴到“存储库 URL”文本框中，如果访问存储库需要您的 Github 凭据，请提供它们。请确保凭据正确，然后点击“继续”按钮。这将验证到您远程存储库的连接，在下一个屏幕上，您可以为您的项目和构建配置指定名称。

点击“继续”按钮进入下一个屏幕。

c. 配置构建步骤

TeamCity 将扫描存储库，并根据项目类型列出在扫描过程中自动检测到的构建步骤。由于我们将项目维护在 Visual Studio 解决方案中，并且我们只会对解决方案进行更改，因此请选中“Visual Studio (sln)”旁边的复选框，然后点击“使用选定的”按钮。

这将创建构建步骤。我们需要配置目标属性，为此，请点击新创建的构建步骤上的“编辑”链接。

Runner 类型和解决方案名称会自动填充，因为它们是从远程存储库导入的。我们需要选择数据库项目正在从中构建的 Visual Studio 版本。点击用于选择 Visual Studio 版本的组合框，然后从下拉列表中选择 Visual Studio 版本。就我而言，我选择了 Visual Studio 2019，因为我的数据库项目是在 Visual Studio 2019 中开发的。您可能需要根据您使用的 Visual Studio 版本选择 Visual Studio 2017 或 Visual Studio 2015。

选择您的 Visual Studio 版本后，点击“保存”按钮，构建步骤的更改将被保存。

我们也可以在此屏幕上指定“配置”和“命令行参数”，但稍后我们会回来处理。

点击页面顶部的导航栏中的“项目”选项卡，您应该会看到您的数据库项目已创建，以及一个具有您在创建项目时指定的名称的构建配置。

d. 运行构建配置

由于这是一个新创建的项目，还没有构建可供显示。因此，请点击“运行”按钮从存储库运行构建。一旦您点击按钮，构建列表将添加一条带有“正在运行”状态的条目。

构建将花费几秒钟到几分钟，具体取决于您的项目大小，如果构建成功，状态将更新为“成功”，如果代码中有任何错误，则更新为“失败”。在本例中，由于我们链接的存储库中没有错误，因此构建成功。

e. 创建发布配置文件

我们现在必须为我们的数据库项目创建一个供 TeamCity 使用的发布配置文件。此配置文件将包含目标数据库设置、版本、脚本名称和目标连接字符串。这可以从 Visual Studio 完成，方法如下。

右键单击数据库项目，然后点击“发布”。在弹出的窗口中，我们可以通过点击“编辑”按钮并从可用连接列表中进行选择来指定目标数据库连接。

一旦定义了连接字符串，我们就需要将配置文件保存为项目中的 XML 文件。点击“另存为配置文件…”按钮并为配置文件选择一个名称。由于当前场景是针对开发服务器的，因此我们将其命名为 *dev.publish.xml*。保存后，将在数据库项目中添加一个新文件，该文件在解决方案资源管理器下可见。

f. 在 TeamCity 中配置发布配置文件

接下来，回到 TeamCity，我们必须指定需要使用此发布配置文件来发布数据库。打开 TeamCity Web 仪表板，进入您的项目 -> 构建，然后点击构建中的“编辑”。

在配置页面上，将此命令输入到“配置”文本框中，然后点击“保存”按钮。

 

/p:SqlPublishProfilePath=”<发布配置文件的名称>”

将发布配置文件的名称替换为您在前面步骤中使用的名称。在这种情况下，命令如下：

 

/p:SqlPublishProfilePath=”dev.publish.xml”

至此，我们的 TeamCity、Github 和 Visual Studio 连接设置已完成。

g. 测试持续集成

根据持续集成的定义，推送到我们 Github 存储库的任何微小更改都应该会在我们的 TeamCity 服务器上触发新的构建。让我们看看当我们进行一个小更改并将其推送到 Github 并合并到主分支时会发生什么。

对于此测试，让我们在新创建的存储过程中添加一个新的存储过程，并将其推送到我们 Github 存储库的主分支。

提交此更改并将其推送到我们 Github 存储库的主分支。

推送完成后，等待几秒钟，然后在 TeamCity 服务器的仪表板上查看。会自动触发一个构建；并且其状态显示为“待定”。

它将自动执行构建过程，并且状态会根据构建结果更新为“成功”/“失败”。在本例中，构建成功。

如果您点击“成功”链接并切换到“更改”选项卡，它将显示自上次构建以来所做的更改数量。

它显示了从我们的存储库获取的完整日志，该日志在将其连接到 TeamCity 后获取。

由此可见，我们的持续集成已成功设置。我们无需经过 Visual Studio 的构建过程即可构建项目。您可以尝试进行几次以自行验证。

h. 错误的构建

在上一个部分中，我们看到在将任何更改推送到我们的远程存储库后，项目会成功构建。但如果签入的代码有错误怎么办？在这种情况下会发生什么？让我们在代码中引入一个错误，看看会发生什么。

让我们在新建的存储过程中添加一个错误的语句，并将代码推送到我们的存储库。

提交此更改并将其推送到主分支。

等待几秒钟，让 TeamCity 构建项目，它将显示存在编译错误。

点击错误以查看错误的详细信息、导致错误的更改以及提交来源的详细信息。

这样可以轻松识别构建错误的根本原因。我们还可以设置在 TeamCity 中发生错误时接收电子邮件通知。这也很容易做到，但目前超出了本课程的范围。

关注点

至此，我们数据库项目的持续集成系统设置和测试已完成。

但是，在每个项目中，您都需要将项目的构建复制到其他环境，例如测试环境、预生产/暂存环境，最后是生产环境。虽然您可以通过为每个服务器使用单独的发布配置文件，并使用 TeamCity 中的发布配置将数据库发布到不同的环境来实现这一点，但这并不是最理想和自动化的方法。这就是持续交付/持续部署发挥作用的地方。

下一篇：使用 TeamCity 和 Octopus 实现 SQL Server 数据库持续部署

历史

• 2019 年 10 月 20 日：本文初稿