如何跟踪部署的文件

Question

我们目前正在寻找更好的替代方案来替代我们当前的部署方式。我正在寻找任何建议。请注意，我们使用的当前系统是我使用过的唯一系统。不过我们很不高兴，因为它很容易出错（你会在细节中看到我的意思）。另请注意，我们正在从 SourceSafe 迁移到 TFS。

我们的公司：
我为养老金系统工作。我们的大部分代码都在内部使用，尽管其中一些在我们的外部网站上使用。

架构：
我们的大部分代码都是基于 2 层的。我们的数据库方案非常大……我们有 6000 个存储过程和 1000 个表。开发人员同时开发 .net 代码和存储过程。

我们当前的部署如何运作：
在 sourcesafe 中，我们有 3 个根文件夹 $/Dev、$/Test、$/Prod，它们对应于 dev/test/prod 数据库。

我们有一个自制的问题跟踪应用程序。我们将处理 $/Dev 分支中的所有问题。然后，我们将创建一个文档，其中包含我们更改的每个文件以及该文件的 sourcesafe 版本号（存储过程/.sql 文件与其他所有文件一样放在 sourcesafe 中）。这些将提供给部署人员，他会将所有文件从 $/dev 移动到 $/test 文件夹。然后其他部署人员将构建我们所有的应用程序并针对测试数据库执行所有存储过程更改。该问题将由我们用户社区的指定测试人员进行测试，一旦签署，文件将从 $/dev->$/prod 移动。部署团队有一个电子表格，以确保任何文件都不会进入 $/Prod，除非它被签署。

我们面临的问题：
首先应该很明显这是多么容易出错。文件丢失或文件版本不正确很常见，尤其是对于大型项目。

我想要任何建议，或者如果有人对部署策略有一些很好的阅读。正如你所看到的，我们与传统的公司有很大的不同，传统的公司只有发布构建类型的结构，我读过的大多数东西都是针对这种结构的。

Answer 1

我建议在 TFS 中有 3 个分支：DEV/TEST/PROD。

无需制作文档来跟踪 DEV 中的所有更改，只需让 TFS 为您完成。当您准备好将更改推广到 TEST 时，只需从 DEV -> TEST 进行合并（这在 TFS 术语中称为反向集成）。

如果您希望能够在 DEV 中同时处理多个“问题”，并且只促进与某个问题相关的更改，您可以使用作为 DEV 分支的子级存在的功能分支。只有当一个问题完成后，它才会移动到 DEV 分支。如果您使用这种分支策略，您可能不需要单独的 TEST 分支，因为您的测试人员可以简单地在 DEV 之外进行操作，其中仅包含已完成的问题。

对于部署，建议取决于您究竟需要部署什么。由于您只提到了数据库，因此我将专注于可用的工具。您可以在 Visual Studio 中创建一个数据库项目，它表示某个时间点的数据库架构和数据。就像任何其他 VS 项目一样，这是源代码控制的。当您的部署团队希望部署它时，他们可以使用 Visual Studio 或命令行工具（对于操作类型的员工来说更常见）。该工具查看 VS 中的 DB 项目并将其与实时数据库进行比较，并生成一个 sql 脚本，您可以对实时数据库执行该脚本以使其与 VS 项目匹配。整个过程可以很容易地自动化（最好是在 TFS 构建中）。

我的目标是定义一个 TFS 构建，该构建可以在任何时候触发代码被检入 TEST（或 DEV，如果使用功能分支）。这会自动构建您的所有代码，并将任何数据库和其他工件部署到适当的测试环境。