部署和 TFS，一般问题

Question

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

目前，该小组可以访问我们当前在 VSS 中的代码存储库，并使用 VSS 部署已签入 VSS 的代码。

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

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

我们可以将代码签入 TFS，但该组执行部署所需的最少软件是什么？团队资源管理器客户端访问就足够了吗？

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

让我感到困惑的是项目本地的 bin（二进制）文件是否进入 TFS？是这样吗，这不会给其他开发人员带来问题，因为只有 1 个开发人员（检查了二进制文件的那个）实际上可以调试，因为调试需要对二进制文件进行写访问？这是否意味着不应将二进制文件签入 TFS？但最终，如果您从 TFS 部署，则必须将二进制文件添加到 TFS。它们是作为单独的（编译的）应用程序节点添加的吗？如果是这样，这听起来真的很难看。我会假设不会。如何确保二进制文件与我们用特定版本号标记的源代码相匹配？

显然，我一无所知。有人能给我大致了解一下您如何处理版本控制和部署，尤其是使用 TFS 吗？

Answer 1

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

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

如您所述，应从开发人员无法访问的 QA 或暂存环境手动触发生产部署以遵守 SOX 规则。

Jaxidian 在研究持续集成方面提出了一个很好的观点。 TFS 支持在签入时触发构建，这使得 CI 成为可能。

Answer 2

一种最小的可能性（即相对简单且使用免费软件）是使用 Powershell 脚本使用 MSBuild 进行编译。要使用您的源代码管理，you can use Subversion，也可以编写脚本。

我建议您对持续集成场景进行一些研究，以详细了解您的问题。