级别： 初级 Doug Miller, 前 IBM Rational Build Forge 传播者, IBM
2007 年 8 月 15 日 
阅读集中构建和发布过程是如何服务于地域上分布的软件开发团队的。
来自 The Rational Edge。
 [编者的话：这篇文章的早期版本发布在CM Crossroads上。
您对这句话听到过多少次：“这个构件在我的机器上能很好的运行，但是我不明白为什么集成的构件就不能工作。”或者下午四点半从构架工程师那收到一封紧急邮件，声称：“我们需要检查库中所有的源代码，并在下午六点进行同步，因此我们要整夜运行一个最终的构件。”
这些情况以及类似于它们的情况，都是分散式构建和发布管理的结果。更糟糕的是，他们将这些作为标准。当今大多数公司都有非常分散的、未受控制的政策，并且在实行管理构建和发布过程。因此当组织充分投资源代码配置管理系统和自动测试系统时，它们之间的桥梁就会留给手工来完成。
集中的原因
许多人会争论说地域分布式团队，和即使是由国内和国外开发者们组成的组织上分布的团队，用分散式构建和发布系统来服务效果会更好。但是我极力主张的是，相反的情况才是正确的 -- 您的组织越分散，您就越需要执行集中构建和发布过程。
没有集中的访问和控制，一致的政策和过程不能在所有涉众中执行。通过集中执行您可以消除信息中的缺陷并能最终向团队贡献更大的生产力和更多的安全数据。事实上，集中构建和发布管理有利于通信、可见度，分享以及简便地对地域分布式团队进行利用。当您在更广阔的环境中考虑构建和发布管理时，这比仅仅在编译或者构建的步骤中显得尤其正确；如果进行更充分的思考，构建和发布管理功能像一个自动框架一样，能支持一个发布工作流，这个工作流是可重复的，并且能够从一个中心视图进行方便的监控。
一个分布式的构建和发布场景
想象这样一个场景。一个大型的高科技厂商构建包含内嵌控制系统和 Windows 用户界面的设备来控制这些机器。整个开发团队包括了在三个大陆的四个地点的较小的团队，还包含一个外包的测试团队。用户界面团队通过使用 Microsoft Visual Studio .NET 和 Team Foundation Server 用 C# 来进行开发，然而内嵌的团队则使用 IBM Rational 开发工具用 Java 语言来进行开发，这使问题变得更加复杂，。每个地点对一个最终的产品进行负责，但是所有人都必须在产品交付之前协作工作。要获得成功，所有这些全球分布的团队必须通力合作。
执行一个像这样的地域上分布的模型是集中构建和发布管理过程的完美场景。这个构建和发布工作流是由每个涉众的参与来详细说明的。不同的角色，对管理、报告、构建本身、测试等等的需求也是不同的。每个角色都是由中心管理构建和发布系统来服务的。每个当地的团队都需要通过运行分配到它们站点上的构建系统的子集，来频繁的运行产品片断的构建。根据通常的原则，一个集成的构建工作流必须首先运行，使来自各个站点的源代码库中的源代码进行同步（这个公司利用支持多个站点复制的软件配置管理（SCM）工具）。然后，所有组件的完整的集成构建就可以同时在四个地点的服务器上运行，这样可以排除在站点之间移动大型构建工件的需要。在日常构建完成时，测试过程会通过测试地点的工作流自动开始，测试过程还会在这个地点被监控。因为相同的构建工件已经在各个站点被构建，任何失败的测试或者被修复的缺陷都能够在任何站点重现，使调试和错误更正更简单。
那么最佳的部分呢？因为整个过程是集中管理的，它允许整个过程端到端的文档化 －－ 显示了哪个源代码版本包含在这个构建中，谁修改了它们，已经修复了哪些缺陷，已经运行了哪些测试等等。现在从任何一个地点，整个过程的结果都能够被查看和审计。
四大益处
这听起来是不是太好了而让人难于置信？最初，集中管理分布式的团队听起来似乎是违反直觉的。但是事实上，它解决了分布式开发中的一些大问题：
- 通过分组参与创造“主要的”工作流来满足所有涉众的需求的方式来培养协作精神。这样在小组之间创造了更高层次的沟通，避免了在不整合的流程中犯错误时有过多的人都对这个结果表示不满。
- 环境可以更容易被保护。基于角色的访问建立在适当授权的基础上，可以作为中央管理基础设施的一部分被实现。
- 总体可视度大大提高。关于构建和发布过程的信息都被集中地记录，因此可以从一个地方找到什么将会成为发布候选者以及任何构建的结果。关于构建过程的信息集中存储库同样是一个内置的审计源和报告库。
- 通过移除在当今环境中常见的人工步骤和阶段之间手工传递的过程，整个过程变得到了改进。所有这些的结果是，更多的编码/构建/测试迭代以及更快速的发布周期。
尽管公司已经在投资基础设施来集中源代码管理和质量管理，但是产品化的最后部分仍然广泛地由人工特殊过程来构建和发布管理。为了改经整个软件交付的过程，您应该实施一个集中的构建和发布管理基础设施。这样做的好处很多，回报也十分快。尽管起先它看起来并不是那么直观，但是将一个健康管理的基础设施与软件开发生命周期的片段捆绑在一起的确有很重要的意义。
参考资料 学习
讨论
- 现在开办了一个特别为 Rational Edge 的文章创办的 新论坛，现在您就可以分享您对本文或本期杂志或以前杂志中的其他文章的想法。阅读世界各地您的同行们所说的内容，生成您自己的讨论，或者加入正在进行的讨论。单击 这里 开始。
-
全球 Rational 用户组社区
关于作者  | 
| | Doug Miller，曾经是一名 IBM Rational Build Forge 传播者。现在是一位拥有 25 年多软件市场经验的软件行业资深人员。在 2006 年五月 IBM 收购 BuildForge 时加入 IBM，在这里他是一名市场副总。他先前在大大小小的软件公司中曾担任过执行市场的职位，包括 BuildForge、Authoria、 Hire.com、Dazel(HP)、Powersoft (Sybase)、Candle， 以及 Computer Corporation of America。要想从 IBM Rational 中获得更多关于构建和发布管理的信息，或者如果您对此篇文章有一些疑问，请与 Carey Benge 联系： cbenge@us.ibm.com。 |
对本文的评价
| 
