如何跟踪部署的文件

Posted 2023-03-06

【中文标题】如何跟踪部署的文件

【英文标题】：How to track deployed files

【发布时间】：2011-04-19 13:50:05

【问题描述】：

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

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

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

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

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

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

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

【参考方案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，如果使用功能分支）。这会自动构建您的所有代码，并将任何数据库和其他工件部署到适当的测试环境。

【讨论】：

感谢 Dylan 的出色回应。对不起，我花了这么长时间才回复。我已经考虑过你所说的话，并考虑过我们将面临的问题（如果有的话）。这是问题所在。我们有大约 12 名开发人员，他们一直在解决问题。一旦它们完成，代码就会被迁移到测试中。通常他的用户对您所做的更改不太满意，因此问题又回到了开发人员身上。您必须意识到，有时这些问题也不会立即得到测试。您不希望任何未签名的代码将其变为 prod。可能有点毛茸茸的是......

当我们必须从 Test->Prod 开始时，因为您可能有一个包含多个版本的文件来解决多个问题。您不一定只从 test->prod 合并。

我会使用功能分支，一旦“功能”（错误、用户故事等）标记为完成后，让测试人员在功能分支上进行测试。一旦 QA 签字，它就会被合并到 DEV/TEST 中，以进行潜在的进一步测试和可能的部署到 prod。

这种方法的缺点是每个功能分支都需要多个测试环境。但是，如果您按照听起来目前正在做的事情去做，那么您就会遇到差异问题。如果 TEST 包含功能 1 和 2，则功能 1 会被签署，但功能 2 不会。功能 1 被提升为 PROD 但没有功能 2，然后发现功能 1 仅通过测试，因为它依赖于一些功能 2 代码 == 损坏的 PROD。