所有的团队都应该使用自动构建吗？-InfoQ

我们与 Team Foundation Server 的高级项目经理 Chris Patterson 讨论了在现代化应用程序开发中，自动构建与持续交付所扮演的角色。Team Foundation Service 是由 Microsoft 托管的 Team Foundation Server。

InfoQ：你是否觉得所有的团队都应该使用自动构建？如果答案为是，为什么？如果为否，那么在何种环境下能体现出它的重要性呢？

Chris：简短的回答是：是的，所有团队都应该使用。首先，我想区分一下代码编译与构建。我认为一个构建应该起码包含运行你的单元测试，否则的话就仅仅是代码编译而已，而这仅针对那些无法通过编译的项目才能起到作用。随着 HTML5 和 JavaScript 越来越多地被项目所采用，甚至使用在原生的 Windows 应用中，单纯的编译步骤已无法给你初级的反馈了。因此，单元测试现在成为了你和你所引入的 bug 之间的第一道防线。我甚至建议只有一个人的团队也要搭建自动构建系统。

记着这一点，你会发现使用自动构建的诸多好处。

首先它为流程的规范化带来好处。自动构建促使开发者或开发团队在创建软件的同时建立并维护一个可重复的、文档化的流程。多数开发者都在不同场合被“在我的机器上能够运行”这种 bug 所困扰。典型的原因是因为开发者工作机上的某些依赖项没有安装在测试或者客户环境上。持续的、可重复的自动构建流程能促使团队保证他们的软件在 IDE 和开发者工作机之外也能够编译并运行基本的单元测试集，这有效地避免了上述 bug 的发生。

除此之外，自动构建也有助于发现及突出一些其它常见问题：

某个开发者的签入破坏了构建

某个开发者忘了签入某个重要文件或者配置变更

你的构建脚本不能运行，或者你的软件不能通过单元测试了

关于软件工程流程中自动构建的重要性的好文章有很多，Martin Fowler 就有一个极好的例子。

InfoQ：你是否认为要想成功应用自动构建，必需了解如何编写 MSBuild脚本？

Chris：MSBuild 是一门创建自动构建脚本的技术，也在 Visual Studio 中使用。从这个角度来看，如果你使用 Visual Studio 进行工作，你应该熟悉 MSBuild 并了解如何编写脚本。

.NET 社区中还流行着其它一些构建脚本工具，例如 NAnt 和 PSake 等等。我个人对它们虽然并不十分精通，不过我的确知道大家对它们热情十足。

我们在 Team Build 中组合使用了 MSBuild 和 Windows Workflow。MSBuild 用来处理 Visual Studio 解决方案和项目文件，我们用它进行代码自动编译。从 TFS 中获取你的代码，执行 MSBuild，运行单元测试并将结果写回 TFS 这一整套流程则是由 Windows Workflow Foundation 完成的。这种组合建立了一个非常强大而灵活的系统，开发者可以利用它实现完全的自动化，包括构建、测试环境管理甚至是生产环境的部署。

不过，如果你使用其它技术，那么你就需要了解如何运行它的构建系统。

InfoQ：你觉得 TFS 在怎样的自动化部署（例如持续交付）场景中表现得特别优秀或者糟糕？

Chris：Team Build 的一大优势是你可以做任何想做的事，但这也可能是它最大的弱点。Windows Workflow 运行时功能非常强大并且适用。不过这对开发者而言意味着一定的学习曲线。对这个平台有所钻研并真正了解它的人能完成连我们都想象不到能为客户实现的功能，而对于不了解 WF 的开发者来说，即使是简单的构建定制也会是一个挑战。这意味着，Team Build 对于任一种自动化部署机制都是一个好的选择，但对开发者来说未必能马上了解如何使用它实现目标。

为了改善开发者在持续交付方面的体验，我们和 Azure 团队合作，提供了从 Team Foundation Service 到 Windows Azure 之间一个无缝的持续交付工作流。只需数次点击，开发者就能够将他们的 Team Foundation Service 帐号与他们的 Azure 订阅连接起来。这个流程同时还创建了一个预配置的构建定义，能够将 web 网站或云服务部署到该订阅中。开发者所要做的只是在他们的解决方案中指明该构建定义，其余的部分都将由我们完成。

今后，我们期待将更多的此类方案提供给 Team Foundation Service 的客户，以及在内部的防火墙中搭建 TFS 的客户。

InfoQ：有人主张持续交付不仅仅针对 QA，也可以应用到生产环境本身。这意味着，一旦自动化测试通过，它就会在没有任何人工干预的情况下自动部署到生产环境。你对这个观点的看法是什么？

Chris：我非常提倡为 QA 实现持续交付，我认为能够将可运行的产品及变更交付给你的测试人员，是提高你的团队速率及软件质量最好的方法之一。再有，如果你都不能为 QA 实现持续交付，那更不可能应用到生产环境上。

为生成环境实现持续交付在某些地方正在流行起来，我相信对某些类型的业务和产品来说这是个长远之计，但对其它业务和产品就未必适用。它对开发者的自律性有着极高的要求，并且对你的自动构建要有足够的自信，确保它能够捕获任何类型的错误，而不让问题发布到客户那里。

InfoQ：对比那些独立的构建服务器，例如 CruiseControl，你觉得使用 TFS 构建 agent 的优势是什么？

Chris：主要的优点在于其集成度。Team Build 是 TFS 的一部分，在安装包和 service 中都有提供，这意味着你拥有了整套设计的方案。如果你遇到任何问题，我们也将为你提供世界级的支持。Team Build 包含了一套预配置的模板，支持 Visual Studio 解决方案和 Visual Studio test runner，这使开发者能在几分钟内轻松上手并运行构建。对于 Team Foundation Service 来说，开发者甚至不需要安装构建 agent。我们为 service 提供了构建 agent，能够构建绝大多数你能在 Visual Studio 中创建的项目。

当然，独立产品的一个优势就是来自社区方面的众多支持。CruiseControl 或 Jenkins 等工具有着丰富的插件，以提供不同的功能。另外，它们的 agent 都能够运行在 Linux 和 MacOS 平台上。我们有许多客户同时使用 Team Build 和独立的构建服务器。所有 Windows 平台上的产品使用 Team Build，而运行在其它平台上的产品使用独立的构建服务器。

InfoQ：是否有计划推出 Java、iOS 及 Android 平台上的构建 agent？

Chris：在这个新平台不断出现的软件开发世界，我们将持续改善在其它平台上的功能。

我们提供了一系列的工作流 activity 以及 MSBuild 任务，以允许你使用在 Java 社区中非常流行的 Ant 和 Maven 实现自动构建。实际上，我们在内部构建 Team Explorer Everywhere 产品时也使用了这些用 Java 编写的 activity。由于 Android 开发环境同样基于 Eclipse 和 Java，我们也可以使用相同的技术。

目前，iOS 应用还只能在 Mac 上开发，而我们还没有能够运行在 Mac 上的 agent。

关于作者

Chris Patterson 是参与 Team Foundation Server 开发的高级项目经理，他在软件行业已工作了 15 年，有着多种技术的工作经验，包括经典的 ASP、VB、Java 及.NET。在 2005 年加入 Microsoft 之前，他就职于 TogetherSoft 及 Borland，通过指导和培训帮助客户改进他们的软件开发流程。在 Microsoft，他负责 Visual Studio 2008 及 2010 中负载、web 及手动测试的特性，目前他负责 Team Foundation Server 和 Team Foundation Service 中的构建自动化组件的工作。他乐于帮助客户解决问题，阅读和学习技术和陪伴家人。你可以在 Twitter 中通过 @chrisrpatterson，或者在产品论坛中找到他。