TFS 2012:将二进制文件与构建和源代码相关联

Question

我开始深入研究TFS 2012，我对这些层、构建服务器、控制器和代理是如何工作的，以及不同的构建脚本如何具有不同的配置和项目有了基本的了解。

然而，我正在努力解决的一件事是对我们的源代码控制解决方案的要求，即我需要能够证明特定的变更集或搁置集生成了特定的构建。也就是说，给定一个特定的二进制文件，我可以指向生成该二进制文件的发布变更集。我还应该能够指向合并到release分支中的测试变更集。这里的想法不仅仅是职责分离，而是验证因为发布和测试变更集是相同的，所以代码审查者没有将代码注入到项目中。

我读过关于“二进制提升”的one blog post --这个概念在我的情况下有用吗？我很难找到这个二进制提升是如何在TFS中设置的。

Answer 1

部署

开箱即用的TFS并不真正支持部署，它可以在构建时部署到一个位置，该位置通常是一个测试服务器(想想实验室管理)。TFS 2012内置了对Azure部署的支持，但它们仍然会在构建结束时发生，并且构建工件不能自动部署到新位置。

您可以修改构建模板以允许发布到不同的位置，但对于每个环境，这仍然是一个全新的构建，而不是真正的二进制升级。

然而，TFS确实有一个构建质量的概念，当这个质量发生变化时，它实际上会触发事件。TFS Deployer是一个与质量变化事件挂钩的第三方工具，可以执行powershell脚本。这意味着只需简单地更改下拉值，您就可以自动启动一个脚本，该脚本将发布到您想要的任何环境。您可以将构建质量列表(每个团队集合)自定义为环境(dev、uat、staging、production等)的列表，然后脚本会确定将特定构建发布到何处。

VS2012还对web deploy进行了一些很好的改进，这意味着部署配置与项目一起存储在源代码控制中，这在理论上意味着它们将在drop文件夹中可用，供TFS Deployer使用。

我不相信TFS保留了构建质量的历史，这意味着您不能真正使用构建质量历史来维护部署到哪个环境的列表。不过，您可以相当容易地将此信息记录为部署脚本的一部分。或者至少向build中添加一个自定义的摘要节点，其中包含有关该版本的信息。

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文件导入中，以确保版本之间不会发生浏览器缓存。

Thoughts

就我个人而言，我希望微软意识到xaml构建工作流试图做的事情太多了，它们分离了不同的关注点(构建、测试、部署……)分成不同的脚本化部分。当然，这要等到TFS的下一个主要发布版才能实现，这是几年后的事了。尽管有了Team Foundation Service，但他们正试图更快地迭代，因此他们实际上可能会在不久的将来将Azure部署内容扩展为更有用的东西。