SOX要求我们有一个单独的组将我们的ASP.NET Web部署到生产中。
目前，该组可以访问VSS中的当前代码存储库，并使用VSS部署已检入VSS的代码。
如何对Web应用程序进行部署？
作为开发人员，我使用Visual Studio中的Deploy功能将代码部署到对应于IS虚拟文件夹的网络共享，但我认为我们不能指望部署组将购买副本Visual Studio只是为了进行部署。
我们可以将代码检查到TFS中，但该组执行部署所需的最低软件是什么？ Team Explorer Client Access是否足够？
我知道Team System具有自动构建应用程序的功能。人们通常是通过将QA环境中的aspx和dll文件复制到生产环境来部署到生产环境，还是通常直接从TFS甚至VS部署？在我看来，首选的方法是从QA环境进行部署，因为这是必须已经批准发布的环境，或者应该将这些文件检入TFS并从TFS部署，假设您可以从TFS部署
令我困惑的是，项目本地的bin（二进制）文件是否会进入TFS？是这样，这不会给其他开发人员带来问题，因为只有1个开发人员 - 经过二进制检查的开发人员 - 实际上可以调试，因为调试需要对二进制文件进行写访问吗？这是否意味着不应将二进制文件检入TFS？但最终，如果从TFS部署，则必须将二进制文件添加到TFS。它们是作为单独的（编译的）应用程序节点添加的吗？如果是这样，这听起来真的很难看。我不会假设。如何确保二进制文件与我们用特定版本号标记的源代码匹配？
显然，我很无能为力。有人可以让我大致了解如何使用TFS处理版本控制和部署吗？
答案 0 :(得分：1)
听起来您在询问使用TFS进行部署的最佳做法是什么。来自TFS团队的book应该回答您的大部分问题。 TFS＆amp;和TFS之间的巨大思维差异默认情况下，VSS不会“锁定”文件被其他开发人员编辑。 TFS具有相当不错的合并功能来处理对同一文件的更改。 TFS书籍更详细地解释了这一点以及为什么它是一件好事。
对于应用程序二进制文件的处理，它们通常应由构建过程生成，并自动部署到目标环境（dev，qa，staging）。您的代码所依赖的第三方二进制文件将与您的源代码一起签入，以确保构建过程具有所有必需的程序集。
正如您所提到的，应该从开发人员无法访问的qa或暂存环境手动触发生产部署，以符合SOX规则。
Jaxidian对研究持续整合提出了一个很好的观点。 TFS支持在签入时触发构建，这使CI成为可能。
答案 1 :(得分：0)
一种最小的可能性（即相对简单和使用免费软件）使用Powershell脚本使用MSBuild进行编译。要使用源代码管理you can use Subversion，也可以编写脚本。
我建议您对持续集成方案进行一些研究，以了解有关您所询问的内容的更多信息。