敏捷与结构性模块化（三）

该系列的第一篇文章介绍了结构性模块化和敏捷的根本性的关系，在第二篇中我们了解到如何使用OSGi 实现高度敏捷和高度可维护的软件系统。

第三篇文章基于标题为“现实世界的挑战：基于OSGi/Bndtools 的开发、发布和版本控制的工作流程”（ Workflow for Development, Release and Versioning with OSGi / Bndtools: Real World Challenges， http://www.osgi.org/CommunityEvent2012/Schedule ）的演讲。在这篇演讲中西门子团队展示了这些业务驱动的解决方案。这些方案实现了基于 OSGi 的高度敏捷的 _ 持续 __ 集成环境 _。

需求

西门子公司技术研究部门由许多具有不同技能的工程师所组成，他们的领域涵盖计算机科学、数学、物理、机械工程和电气工程。该部门向西门子的业务单位提供了基于神经网络技术和其他的机器学习算法的解决方案。比起理想化的概念，西门子的业务部门更需要可以运行的样例产品。所以该部门需要为业务部门快速地建立解决方案的原型。

图 1： 西门子的产品库

为了快速地建立原型，理想的方案是建立一个软件组件库，并以此为核心，这样西门子的研发团队就可以快速地发布新的功能，业务部门也能够很快地提供新的产品。

实现这一目标所采用的解决方案必须满足以下要求：

1. 可重复构建：解决方案必须能够保证即使过了很多年，依然能够基于完全相同的源码和依赖进行重新构建。这样西门子可以持续支持多个被不同客户使用的发行版本。
2. 可靠的版本：通过使用 OSGi 的语义化版本命名，构建过程中所有发布的组件版本永远能够正确地对应其语义，西门子可以快速且可靠地组装出组件的集合（包括他们自己的软件、第三方软件和开源软件），并且高度确信它们可以正常运作。
3. 全程可追踪：软件所发布的所有组件，与 QA 测试过的组件，总是完全相同的，并且，能够追溯到它们的源码和依赖性。这使得从测试状态变为可发布状态的过程中，不再需要进行重新构建工作。

最后，单独的软件组件和最终所组成的产品，必须有统一的应用启动、生命周期和配置方式。

解决方法

他们选择 OSGi 作为实现模块化的框架，这个决定基于 OSGi 技术的成熟度、支撑 OSGi 实现的开放行业规范以及 OSGi 联盟的技术管理。这个 _ 持续 __ 集成 _ 的解决方案基于开发和发布 / 产品的 OSGi Bundle 库（Development and Release/Production OSGi Bundle Repository, OBR）. 由于 OSGi 的组件完全是自描述的（_ 需求和功能 _ 的元数据），特定的业务功能可以动态地根据模块间的依赖关系从有关的库中自动加载。

西门子的团队也想实施“所测即所发布” (What You Test Is What You Release, WYTIWYR) 的最佳实践。用于发布的软件不应该在测试以后重建，在测试过程中，构建环境有可能会发生改变。许多组织确实在发布过程中重新构建软件产品，比如从 1.0.0.BETA 变为 1.0.0.RELEASE。这一常用但不算太好的方法是因为依赖关系是由组件的名字来实现的。

最后从技术角度来看，解决方案必须有以下特点：

• 可以与标准的开发工具一起使用，如 Java 中的 Eclipse；
• 对 OSGi 强有力的支持；
• 支持不同软件库的理念；
• 支持自动的语义化版本（即自动计算需要 _ 导入的版本范围 _，并且自动增加 _ 输出的版本号 _）——因为这一过程对人类来说实在太繁琐了！

基于这些原因西门子公司选择了 Bndtools 。

解决方案

下面一系列的图示解释了西门子公司解决方案的关键属性。

图 2: 以库为中心、快速迭代并且在开发过程实现版本重用

Bndtools 是一个以库为中心的工具，让开发者可以从多个 _OSGi Bundle__ 库（OBR）_ 中取得 OSGi 的 bundle。除了本地用于开发的读写库之外，开发者也可以从其他只读库中寻找 OSGi bundle，比如，组合使用公司内部的开源库、公司专有的库和经批准的第三方库等。开发者可以很容易地从一个经认证的库列表中选择所需的库，并从中选取所需的组件，并把它们拖到 Bndtools 的工作区之中。

开发者将本地工作的代码放入 SVN 库。SVN 库只存放在制件（Work-In-Progress, WIP）。Jenkins 的 _ 持续集成 _ 服务器不停地构建、测试并将建好的 OSGi 组件加入共享的只读开发库中。这些组件可以马上通过 Bndtools 被所有的开发人员使用。

随着开发人员的快速开发，每天会进行多次的构建，这将会变得难以管理，对每次开发构建都增加版本号确实是没有意义的。由于这个原因，在开发环境中我们允许重复地使用版本号。

图 3: 发布

就绪之后，开发团队可以将模块发布到只读的 QA 库。

图 4: 锁定

当模块一旦进入 QA 后，在开发库中它就变成只读的了。任何修改或重新构建都会失败。如要修改，开发人员必须增加版本号。

图 5: 版本递增

开发人员可以使用 Bndtools 的自动化语义版本功能来实现版本的递增，从而确保当前的版本号能够表达出目前的 WIP 版本与之前版本的区别。根据前面文章中对语义版本规则的讨论：

1. 1.0.0 => 1.0.1 … “缺陷修正”
2. 1.0.0 => 1.1.0 … “新的功能”
3. 1.0.0 => 2.0.0 … “破坏性的变化”

我们可以看到新的 1.0.1 版本是一个缺陷修正版本。

再看敏捷成熟度模型

在前面的文章中我们讨论了敏捷成熟度模型。根据该模型对西门子的解决方案进行评估，所有高度敏捷系统所必需的特征它都满足。

• 委托（Devolution）：通过 Bndtools 对 OSGi 库进行方便的使用
• 模块化及服务（Modularity&Service）：整体的解决方案。决策中必不可少的一部分就是采用以 OSGi 为中心的方案。

正如 Kirk Knoernschild 在 DEVOXX2012 上的演讲“自上而下的架构（Architecture All the Way Down）”所讲的，敏捷运动专注于实现在敏捷开发时社交和流程（Social and Process）的方面，但根本性的因素——“结构性的模块化”——并没有被重视。那些想在庞大的代码库中实现“敏捷”的人对此应该深有体会。西门子公司通过OSGi 实现结构性的模块化，由此达到敏捷的目标，与此同时也实现了社交和流程方面的敏捷开发。

Bndtools 是促成这一解决方案的关键。同时，西门子公司的业务需求也反过来促进和形成了 Bndtools 的关键功能。在此我感谢西门子公司允许这些工作成果被 Paremus 和 OSGi 联盟所使用。

Bndtools 的更多信息

Bndtools 基于 Peter Kriens 的 bnd 项目，这个 GITGHUB 项目由 Neil Barlett 在 2009 年早期开始，bnd 是 _ 业界创建 OSGi bundle 的事实标准 _。Bndtools 包括了 Neil 在培训时帮助学生开发的一系列工具，以及 Paremus 在 SIGIL 项目上的一些工具。

Neil Barlett 已经多次陈述过 Bndtools 的目标，即让开发敏捷和模块化的 Java 应用变得更容易，而不是更难。西门子的项目显示 Bndtools 能够迅速达到这个核心的目标。Bndtools 得到了越来越多的开源社区和软件供应商的支持，这其中就包括了 Paremus 的长期支持。现阶段 Bndtools 的目标是支持 OSGi Blueprint、与 Maven 更好的集成以及在 OSGi 云计算环境里便捷地加载运行时发布版本的适配器（runtime release adaptor），这样的环境包括 Paremus 的 Service Fabric。

更多关于 OSGi／Bndtools 的理念可以在 Neil Barlett 2013 年 5 月在日本 OSGi 用户组的演讲材料找到： NeilBartlett-OSGiUserForumJapan-20130529 。对那些想实现 Java/OSGi 敏捷开发的公司来说，Paremus 提供这方面的工程咨询服务，以帮助他们实现该目标。Paremus 也为各公司的开发人员提供现场的高级 OSGi 培训。如有兴趣可以联系我们。

最后的章节

在敏捷和模块化系列的最后一篇里，我会讨论敏捷和运行时平台（Runtime Platform）。敏捷的运行时平台是Paremus 从2004 年来就专注的领域，那时Service Fabric 刚刚发布最初的版本，当时还被称为Infiniflow。对于敏捷运行时环境的追求使Paremus 从2005 年起采用了OSGi，并在2009 年成为了OSGi 联盟的会员。

但是OSGi 的运行环境并不统一。尽管OSGi 在基础上使敏捷的运行时环境成为可能，但单纯地使用OSGi 并不能保证运行环境的敏捷。用OSGi 建立脆弱的系统也是可能的。下一代的动态模块化平台，如Paremus 的Service Fabric，不但必须使用OSGi，而且必须要采纳OSGi 本身所基于的根本性的设计理念。

原文地址： https://adaptevolve.paremus.com/?p=1380

作者简介

_Richard Nicholson_ 是 Paremus 的 CEO 和创始人，这是一个 2001 年成立的软件公司，总部位于英国。

在意识到高度可维护以及高度敏捷的系统在本质上必须是高度模块化的之后，Paremus 在 2004 年开始研究下一代的软件系统。这种持续的努力体现在了 Paremus Service Fabric 产品之中，这是一个高度可适应的、基于 OSGi 的自装配运行时，可用于企业级和云环境。作为 OSGi 联盟的主席（2010-2012），Richard 开始推进 OSGi Cloud 并鼓励 OSGi 联盟参与到敏捷软件社区中。

Richard 在很多的研究领域都保持了浓厚的兴趣，这支撑了 Service Fabric 的研发，他的研究领域包括复杂的适应性系统（Complex Adaptive System）以及敏捷（Agility）、模块化组装（Modular Assembly）、结构化多样性（Structural Diversity）和适应性（Adaption）之间的关系。

成立 Paremus 之前，Richard 在花旗集团 /Salomon Smith Barney，领导着欧洲系统工程（European System Engineering）相关的工作。Richard 获得了曼切斯特大学的物理学荣誉学位，并在格林尼治皇家天文台（ Royal Greenwich Observatory）获得天体学物理博士。

Richard 的博客： http://adaptevolve.paremus.com。

Paremus 的博客： http://blogs.paremus.com。

感谢张卫滨对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ）或者腾讯微博（ @InfoQ ）关注我们，并与我们的编辑和其他读者朋友交流。