部署和TFS，一般问题

Question

SOX要求我们有一个单独的小组将我们的ASP.NET网站部署到生产环境。

目前，该组可以访问VSS中的当前代码存储库，并使用VSS将已签入VSS的代码部署到该服务器中。

Web应用程序通常如何部署？

作为开发人员，我使用Visual Studio中的Deploy功能将代码部署到与IS虚拟文件夹相对应的网络共享中，但我认为我们不认为我们可以期望部署组将购买副本的Visual Studio只是为了部署。

我们可以将代码检查到TFS中，但该组需要执行部署所需的最低软件是什么？团队资源管理器客户端访问是否足够？

我知道Team System具有自动构建应用程序的功能。通常情况下，人们是通过将aspx和dlls文件从QA环境复制到生产环境，还是通常直接从TFS甚至VS直接部署？在我看来，首选的方法是从QA环境进行部署，因为这是必须批准发布的环境，或者这些文件应该从TFS中检入到TFS中并从TFS中部署，假设您可以从TFS中部署。

让我困惑的是，bin（二进制）文件是否是项目本地的 - 是否进入TFS？是这样吗？这对其他开发人员是否会产生问题，因为只有一个开发人员（具有二进制文件的开发人员）才能真正进行调试，因为调试需要对二进制文件进行写入访问？这是否意味着二进制文件不应该被检入到TFS中？但最终，如果从TFS部署，则必须将二进制文件添加到TFS中。它们是作为单独的（编译的）应用程序节点添加的吗？如果是这样，这听起来真丑。我会假设没有。如何确保二进制文件与我们用特定版本号标记的源代码相匹配？

显然，我很无能。有人能给我一个关于如何处理版本控制和部署特别是使用TFS的一般概念吗？

Answer 1

一个最小的可能性（即相对简单并使用自由软件）使用Powershell脚本来使用MSBuild进行编译。要使用源代码管理，you can use Subversion，它也可以编写脚本。

我建议您对持续集成方案进行一些研究，以更多地了解您所问的内容。

Answer 2

听起来像你问什么是使用TFS进行部署的最佳实践。来自TFS团队的这个book应该回答你的大部分问题。 TFS & VSS之间的巨大差异在于，默认情况下，TFS签出不会“锁定”某个文件被其他开发人员编辑。 TFS具有相当不错的合并能力来处理对同一文件的更改。 TFS书籍更详细地解释了这一点，并解释了它为什么是好事。

至于应用程序二进制文件的处理，它们通常应该由构建过程生成并自动部署到目标环境（dev，qa，staging）。您的代码所依赖的第三方二进制文件将与您的源代码一起签入，以确保构建过程具有所有必需的程序集。

正如您所提到的，应该从开发人员无法访问的qa或临时环境手动触发部署到生产环境，以符合SOX规则。

Jaxidian对于研究持续集成有一个很好的观点。 TFS支持在检入时触发构建，这使得CI成为可能。