我们目前正在寻找目前部署方式的更好替代方案。我正在寻找任何建议。请注意我们使用的当前系统是我用过的唯一系统。我们不高兴，因为它很容易出错（你会在细节中看到我的意思）。另请注意，我们正在从SourceSafe迁移到TFS。
我们的公司：
我为养老金制度工作。我们的大部分代码都在内部使用，尽管其中一些代码在我们的外部网站上使用
架构：
我们的大多数代码都是基于2层的。我们的数据库方案非常大......我们有6000个存储过程和1000个表。开发人员开发.net代码和存储过程。
我们当前的部署工作方式：
在sourcesafe中，我们有3个根文件夹$ / Dev，$ / Test，$ / Prod对应于dev / test / prod数据库。
我们有一个本土问题跟踪应用程序。我们将处理$ / Dev分支中的所有问题。然后，我们将创建一个文档，其中包含我们更改的每个文件以及文件的sourcesafe版本＃（存储过程/ .sql文件与其他所有文件一样放在sourcesafe中）。这些将提供给部署人员，他们将所有文件从$ / dev移动到$ / test文件夹。然后，其他部署人员将构建我们的所有应用程序并对测试数据库执行所有存储过程更改。该问题将由我们的用户社区的指定测试人员进行测试，一旦签署，文件将从$ / dev-＆gt; $ / prod移动。部署团队有一个电子表格，以确保除非已签署，否则任何文件都不会进入$ / Prod。
我们面临的问题：
首先，应该明白这是多么容易出错。错过的文件或不正确的文件版本＃文件很常见，特别是对于大型项目。
我想要任何建议，或者有人对部署策略有一些好的读数。正如您所看到的，我们与传统公司有很大的不同，传统公司只有发布构建类型的结构，我读过的大部分内容都适合。
答案 0 :(得分：1)
我建议在TFS中有3个分支：DEV / TEST / PROD。
不要让文档跟踪DEV中的所有更改，而是让TFS为您执行此操作。当您准备将您的更改提升为TEST时，只需从DEV进行合并 - ＆gt; TEST（这在TFS术语中称为反向整合）。
如果您希望能够在DEV中同时处理多个“问题”，并且只提升与某个问题相关的更改，则可以使用作为DEV分支的子级存在的功能分支。只有在问题完成后才会转移到DEV分支。如果您使用此分支策略，您可能不需要单独的TEST分支，因为您的测试人员可以简单地操作DEV，其中仅包括已完成的问题。
对于部署，建议取决于您需要部署的具体内容。由于您只提到了数据库，我将专注于可用的工具。您可以在Visual Studio中创建一个数据库项目，该项目表示某个时间点的数据库模式和数据。这是源控制，就像任何其他VS项目一样。当您的部署团队希望部署它时，他们可以使用Visual Studio或命令行工具（对于操作类型的工作人员更常见）。该工具查看VS中的DB项目并将其与实时数据库进行比较，并生成一个sql脚本，您可以对实时数据库执行该脚本以使其与VS项目匹配。整个过程可以相当容易地自动化（理想情况下在TFS构建中）。
我的目标是定义一个TFS Build，触发任何时候代码被检入TEST（或DEV，如果使用功能分支）。这会自动构建所有代码，并将任何数据库和其他工件部署到适当的测试环境。