Deployment 如何跟踪部署的文件

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

我们公司：
我为养老金制度工作。我们的大部分代码都是在内部使用的，尽管有些代码是在我们的外部网站上使用的

体系结构：
我们的大部分代码都是基于两层的。我们的数据库方案相当大……我们有6000个存储过程和1000个表。开发人员开发.net代码和存储过程

我们当前部署的工作方式：
在sourcesafe中，我们有3个根文件夹$/Dev、$/Test、$/Prod，它们对应于Dev/Test/Prod数据库

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

我们面临的问题：
首先，应该清楚这是多么容易出错。缺少文件或文件版本不正确是很常见的，尤其是在大型项目中

---

我想要任何建议，或者如果有人对部署策略有很好的了解。正如您所看到的，我们与传统公司有很大不同，传统公司只有发布-构建类型的结构，而我所读的大多数内容都是针对这种结构的。

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

与其制作一个文档来跟踪DEV中的所有更改，不如让TFS为您这样做。当您准备将更改升级到测试时，只需从DEV->TEST进行合并（在TFS行话中称为反向集成）

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

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

---

我的目标是定义一个TFS构建，该构建在代码签入测试时触发（如果使用特性分支，则触发开发人员）。这会自动生成所有代码，并将任何数据库和其他工件部署到适当的测试环境。

感谢Dylan的出色响应。对不起，我花了这么长时间才回复。我考虑过你说的话，也考虑过我们可能会面临的问题。问题就在这里。我们有大约12名开发人员，他们一直在解决这些问题。一旦完成，代码就被迁移到测试中。用户对您所做的更改不太满意是很常见的，因此问题会回到dev。您必须意识到，有时这些问题也不会立即测试。您不希望任何未签署的代码进入prod。可能有点棘手的是…当我们必须从Test->prod开始时，因为您可能有一个针对多个问题的具有多个版本的文件。您不必从test->prod进行合并。我会使用特性分支，并在“特性”（bug、用户故事等）标记完成后让测试人员在特性分支上进行测试。一旦QA签字，它将被合并到开发/测试中，以进行潜在的进一步测试和可能的产品部署。这种方法的缺点是您需要为每个功能分支提供多个测试环境。然而，如果你做了听起来像你目前正在做的事情，你就会有一个不同的问题。若测试包含功能1和功能2，则功能1会被签署，但功能2不会。功能1升级为PROD，但没有功能2，然后发现功能1只通过了测试，因为它所依赖的某些功能2代码==损坏的PROD。