对于这篇文章的长度，我深表歉意，但我需要包含很多信息才能得到正确的答案。我希望这不会阻止响应...
我们的商店过去曾使用经典 ASP 对网站进行编码，并将一些较新的 ASP.NET 网站配置为网站。众所周知，这意味着源文件（*.asp、*.aspx和*.aspx.vb（或 *.aspx.cs））文件按原样部署到开发和生产服务器。
配置管理过程是（现在仍然是）完全手动的，包括以下步骤（要求）：
- 复制修改后的文件并将它们存储在“发布”文件夹中以进行归档。
- 复制将被替换的生产文件并将它们存储在“存档”文件夹中以便于回滚。
- 在诊断发布后问题时生成源文件前后的差异报告以供代码审查或一般参考。
- 编写更改代码的开发人员不是执行生产版本的人。原始开发人员需要将源文件移交给其他开发人员，以进行一些额外的测试和生产部署。
为了使情况变得更加困难（不是上面的……而是我在下面谈论的），我们没有遵循正式的发布时间表。随着个别错误或增强功能的完成，它们将被释放。这意味着我们可以轻松地每周向一个站点发布多个版本。一个给定的网站甚至有可能在同一天为各个页面获得两个不同的版本！
自从我加入以来，我一直在尝试将团队过渡到更新的技术，例如 ASP.NET Web 应用程序和 ASP.NET MVC。（我们还承担了用于非 Web 进程的独立应用程序和控制台实用程序的责任……所以我的困境仍然适用。）
这些技术与遗留技术的区别在于预编译。无需部署代码隐藏文件（*.aspx.vb（或 *.aspx.cs）），而是部署 dll 或 exe。这种类型的部署包提出了几个问题（问题？？）。
- 编译源代码后生成差异报告。虽然新修改的源文件位于开发人员系统上，但生产副本是编译后的副本。
- 确保与其他错误或增强功能相关的更改不包含在特定版本中。这将适用于原始开发人员和执行发布的人员。
- 允许原始开发人员将更改的文件传递给其他开发人员进行构建、测试和部署。
到现在为止，我是团队中唯一从事此类网站和应用程序的开发人员，因此不存在上述冲突和问题。（我跳过了差异报告步骤，我自己进行了部署。）但是，我试图推动团队的其他成员接受这一点，并允许更好地分配错误和增强任务。
我们目前正在使用 VSS，但我正在推动（并且很可能会成功）将我们转移到 TFS。我的一些想法是
设置一个单独的构建系统供开发人员使用来进行部署。这将解决两个问题 - (1) 开发人员之间的 Visual Studio 和其他库的不同版本/补丁，以及 (2) 执行发布的人已在本地签出文件以进行其他更改的实例。（当然，这并不能保证构建系统和原始开发人员之间的差异，但至少这意味着发布来自一致的配置。
使用标签仅标记已修改的文件。我的问题是，虽然我可以识别（并下拉构建）修改后的文件，但我如何识别需要包含在构建中但尚未更改的文件。同样，这个想法是不包含与未发布更改相关的已签入文件。
使用标签标记发布的所有文件（修改后的文件和未更改的文件）。我的问题与上一个问题类似......我如何确保另一个开发人员签入的文件（比如他们去度假）进行了不相关的更改，并没有标记并包含在此构建中。
使用标签，我可能会编写一个脚本来为标记版本和先前标记的版本生成差异报告。如果该过程正常工作，那么应该会导致特定版本中包含哪些更改..？
还有其他想法、顾虑、兴趣点吗？虽然我确实对流程有一定的灵活性，但某些要求（如差异报告或某种轻松查看差异的方法以及拥有单独的开发人员/部署人员）很可能是不可触及的。
非常感谢您对此提供的任何帮助。