TFS 2012：将二进制文件与内部版本和源代码相关联 [英] TFS 2012: Correllating binaries to builds and source code

问题描述

我将开始学习TFS 2012，我对这些层以及构建服务器，控制器和代理的工作方式以及不同的构建脚本如何具有不同的配置和项目都有基本的了解。

I'm starting to dive into TFS 2012 and I have a basic understanding of the tiers and how build servers, controllers and agents work and how different build scripts can have different configurations and projects.

但是，我苦苦挣扎的事情之一是对我们的源代码控制解决方案的要求，即我需要能够证明产生的特定变更集或架子集特定的版本。也就是说，给定特定的二进制文件，我可以指向生成该二进制文件的发行变更集。我还应该指出已合并到发行分支中的测试变更集。这里的想法不仅是职责分离，还可以验证，因为发布和测试变更集是相同的，因此代码审查者不会将任何代码注入到项目中。

However, one of the things I'm struggling with is a requirement for our source control solution that says that I need to be able to prove a particular changeset or shelfset produced a particular build. That is, given a particular binary, I can point to a release changeset that generated that binary. I should also be able to point to the test changeset that was merged into the release branch. The idea here is not just a separation of duty, but validating that because the release and test changesets are identical, no code was injected into a project by a code reviewer.

我已阅读一篇博客文章，其中谈到二进制促销-在我的情况下该概念有用吗？我很难找到如何在TFS中设置此二进制升级。

I've read one blog post that talks about "Binary promotions" -- would that concept be useful in my situation? I'm having a hard time finding how this binary promotion is set up in TFS.

推荐答案

部署

开箱即用的TFS并不真正支持部署，它可以部署到构建中的1个位置（通常是测试服务器）（请考虑实验室管理）。 TFS 2012内置了对Azure部署的支持，但是它们仍会在构建结束时发生，并且构建工件无法自动部署到新位置。

Out of the box TFS doesn't really support deployments, it can deploy to 1 location on build which often is a test server (think lab management). TFS 2012 has built in support for Azure deployments, but they still happen at the end of a build and the build artifacts cannot be automatically deployed to a new location.

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

You could modify the build template to allow to release to different locations, but that would still be a fresh build for every environment and not true binary promotions.

TFS确实具有构建质量的概念，并在更改此质量时实际触发事件。 TFS部署程序是第3方工具，可以挂接到质量更改事件并可以执行powershell脚本。这意味着只需更改下拉值，就可以自动启动脚本，该脚本可以发布到所需的任何环境。您可以自定义构建质量列表（按团队集合），以列出环境（开发，维护，阶段，生产等），然后脚本会找出将特定构建发布到何处。

TFS does, however, have a concept of build quality and actually fires off events when this quality is changed. TFS Deployer is a 3rd party tool that hooks into the quality change event and can execute powershell scripts. This means with a simple change of a dropdown value you can automatically kickoff a script that releases to any environment you want. You can customize the build quality list (per team collection) to be a list of environments (dev, uat, staging, production etc) which the script then figures out where to release the specific build to.

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

VS2012 also has some nice improvements to web deploy which means deployment configurations are stored in source control with the project, which in theory means they'll be available in the drop folder for TFS Deployer to make use of.

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

I don't believe TFS keeps a history of build qualities, which means you can't really use the build quality history to maintain a list of what is deployed to which environment. You could fairly easily record this information as part of the deployment script though. Or at the very least add a custom summary node to the build with information about the release.

TFS2012确实能够将内部版本标记为作为Azure的一部分进行部署部署功能，您可以使用脚本将 tfs部署程序的构建标记为已部署，但感觉不是很有用。

TFS2012 does have the ability to mark a build as deployed as part of the Azure deployment functionality, you mark tfs deployer builds as deployed using a script but it doesn't feel very useful.

章鱼部署是另一个值得检查的项目，并且如果您的构建模板创建了NuGet软件包，则可以代替TFS Deployer使用。它需要对生产硬件进行更多控制，因为您需要在每个环境上安装代理以处理发行版，但是它解决了部署中的许多其他问题。

Octopus Deploy is another project that's worth checking out, and could be used instead of TFS Deployer if your build template creates NuGet packages. It requires a bit more control over the production hardware as you need to install agents on each environment to handle releases, but it solves a lot of other issues with deployment.

版本化

一旦您有了一种很好的一致的自动发布方式，使人们不会绕过，您可以考虑增强构建模板以注入生成版本，或将变更集编号作为该自动生成的一部分生成的任何程序集的程序集版本。有许多不同的方法可以执行此操作，并且博客 帖子和工具帮助您实现目标。

Once you have a nice consistent way of automatically releasing that people don't bypass, you can look at enhancing the build template to inject the build version, or changeset number as the assembly version for anything built as part of that automated build. There's a number of different ways to do it and plenty of blog posts and tools to help you achieve that.

或者，您也可以使用自动程序集版本控制（ [assembly：AssemblyVersion（ 1.0。*）] ）为您提供构建发生的日期/时间，其结果类似于1.0.1234.123，其中1234类似于自2000年1月1日以来的日子，而123则是自午夜以来的分钟（我的详细信息此处可能是错误的）。

Alternatively you could just use automatic assembly versioning ([assembly: AssemblyVersion("1.0.*")]) to give you the date/time the build occurred, which ends up like 1.0.1234.123 where 1234 is something like the days since jan 1st 2000, and 123 is the minutes since midnight (my specifics may be wrong here).

如果您要部署网站，那么我强烈建议将当前的构建版本注入html中。这样，您可以检查网站正在运行的版本，而无需访问bin目录。也可以将它作为查询字符串附加到css / js文件导入中，以确保版本之间不存在浏览器缓存。

If you're deploying websites, then I highly recommend injecting the current build version into the html somewhere. This way you can check what version a website is running without needing access to the bin directory. It can also be appended as a querystring to css/js file imports to ensure no browser caching occurs between versions.

思路

我个人希望微软意识到xaml构建工作流试图做太多事情，并且将不同的关注点（构建，测试，部署...）分解为不同的可编写脚本的部分。当然，要等到好几年之后，TFS的下一个主要版本才会发布。尽管他们使用Team Foundation Service试图更快地进行迭代，所以实际上他们可能会在不久的将来将Azure部署的东西扩展到更有用的东西中。

Personally I'm hoping Microsoft realise that the xaml build workflows are trying to do too much and that they split the different concerns (build, test, deployment...) into different scriptable parts. Of course that would not be until the next major release of TFS which is years away. Although with Team Foundation Service they are trying to iterate a lot quicker, so they may actually extend the Azure deployment stuff into something more useful in the nearer future.

这篇关于TFS 2012：将二进制文件与内部版本和源代码相关联的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！