我开始深入研究 TFS 2012，并且对这些层以及构建服务器、控制器和代理的工作方式以及不同的构建脚本如何具有不同的配置和项目有了基本的了解。
但是，我正在努力解决的一件事是对我们的源代码控制解决方案的要求，即我需要能够证明特定的变更集或货架集产生了特定的构建。也就是说，给定一个特定的二进制文件，我可以指向生成该二进制文件的发布变更集。我还应该能够指向合并到发布分支中的测试变更集。这里的想法不仅仅是职责分离，而是验证由于发布和测试变更集是相同的，代码审查员没有将代码注入项目中。
我读过一篇关于“二元促销”的博文——这个概念在我的情况下有用吗？我很难找到如何在 TFS 中设置此二进制促销。
部署
开箱即用的 TFS 并不真正支持部署，它可以部署到构建时的 1 个位置，该位置通常是测试服务器（想想实验室管理）。TFS 2012 内置了对 Azure 部署的支持，但它们仍然发生在构建结束时，并且构建工件无法自动部署到新位置。
您可以修改构建模板以允许发布到不同的位置，但这仍然是每个环境的全新构建，而不是真正的二进制促销。
然而，TFS 确实有构建质量的概念，并且在质量发生变化时实际上会触发事件。 TFS Deployer是一个第 3 方工具，它与质量更改事件挂钩并可以执行 powershell 脚本。这意味着只需简单更改下拉值，您就可以自动启动一个脚本，该脚本可以发布到您想要的任何环境。您可以将构建质量列表（每个团队集合）自定义为环境列表（开发、uat、登台、生产等），然后脚本会确定将特定构建发布到的位置。
VS2012 对 web 部署也有一些很好的改进，这意味着部署配置与项目一起存储在源代码控制中，这在理论上意味着它们可以在放置文件夹中供 TFS Deployer 使用。
我不相信 TFS 会保留构建质量的历史记录，这意味着您不能真正使用构建质量历史记录来维护部署到哪个环境的列表。不过，您可以很容易地将此信息记录为部署脚本的一部分。或者至少在构建中添加一个自定义摘要节点，其中包含有关发布的信息。
TFS2012 确实能够将构建标记为已部署为 Azure 部署功能的一部分，您可以使用脚本将tfs 部署程序构建标记为已部署，但感觉不是很有用。
Octopus Deploy是另一个值得一试的项目，如果您的构建模板创建 NuGet 包，则可以使用它来代替 TFS Deployer。它需要对生产硬件进行更多控制，因为您需要在每个环境中安装代理来处理版本，但它解决了许多其他部署问题。
版本控制
一旦你有一个很好的一致的方式来自动发布人们不会绕过的，你可以考虑增强构建模板以注入构建版本，或者变更集编号作为作为该自动构建的一部分构建的任何东西的程序集版本。有许多不同的方法可以做到这一点，还有大量的博客 文章和工具可以帮助您实现这一目标。
或者，您可以使用自动程序集版本控制 ( [assembly: AssemblyVersion("1.0.*")]) 来为您提供构建发生的日期/时间，最终结果类似于 1.0.1234.123 其中 1234 类似于自 2000 年 1 月 1 日以来的天数，而 123 是自午夜以来的分钟数（我的具体情况这里可能是错的）。
如果您正在部署网站，那么我强烈建议您将当前的构建版本注入到 html 的某个地方。这样您就可以检查网站正在运行的版本，而无需访问 bin 目录。它也可以作为查询字符串附加到 css/js 文件导入中，以确保版本之间不会发生浏览器缓存。
想法
就我个人而言，我希望 Microsoft 意识到 xaml 构建工作流正在尝试做太多事情，并且它们将不同的关注点（构建、测试、部署......）分成不同的可编写脚本的部分。当然，这要等到 TFS 的下一个主要版本，也就是几年之后。尽管使用 Team Foundation Service，他们正在尝试更快地迭代，因此他们实际上可能会将 Azure 部署内容扩展为在不久的将来更有用的东西。