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