首页 / 软件开发 / 数据结构与算法 / 敏捷与结构性模块化（三） 现实世界的挑战

敏捷与结构性模块化（三） 现实世界的挑战2014-08-08 infoq Richard Nicholson现实世界的挑战：基于OSGi/Bndtools的开发、发布和版本控制的工作流程

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

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

需求

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

图 1： 西门子的产品库

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

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

可重复构建：解决方案必须能够保证即使过了很多年，依然能够基于完全相同的源码和依赖进行重新构建。这样西门子可以持续支持多个被不同客户使用的发行版本。

可靠的版本：通过使用OSGi的语义化版本命名，构建过程中所有发布的组件版本永远能够正确地对应其语义，西门子可以快速且可靠地组装出组件的集合（包括他们自己的软件、第三方软件和开源软件），并且高度确信它们可以正常运作。

全程可追踪：软件所发布的所有组件，与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强有力的支持；

支持不同软件库的理念；

支持自动的语义化版本（即自动计算需要导入的版本范围，并且自动增加输出的版本号）——因为这一过程对人类来说实在太繁琐了！

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