作者：Richard Nicholson 翻译：刘剑锋 审校：张卫滨
原文发表于Infoq，经译者同意，发布到社区。
该这一系列的第一篇文章介绍了结构性模块化和敏捷的根本性的关系。在第二篇中我们了解到如何使用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联盟的技术管理。这个基于持续集成的解决方案基于使用了独立的开发和产品发布/产品的OSGi Bundle 库（Development and Release/Production OSGi Bundle Repositoryies, OBR)）. 由于OSGi的组件完全是自我描述的（需求和功能的元数据），特定独特的业务功能可以动态地根据模块间的依赖关系从有关的库中自动加载。西门子的团队也想实施“所测即所发布” (What You Test Is What You Release, WYTIWYR)的最佳实践。用于发布的软件不应该在测试以后重建，。在测试过程中，构建组建环境有可能会发生改变。，许多组织确实在发布过程中重新构建组建软件产品，比如从1.0.0.BETA变为1.0.0.RELEASE。这一常用但不算太好的方法是因为依赖关系是由组件的名字来实现的。
最后从技术角度来看，解决方案必须有以下一下一些特点：
基于这些原因西门子公司选择了Bndtools。
下面一系列的图示解释了西门子公司AG解决方案系统的关键属性元素。
图 2: 以库为中心、，在开发中快速迭代循环，并且在开发过程实现对版本重复使用 Bndtools是一个以库为中心的工具，让开发者可以从多个OSGi Bundle库（OBR）中取得OSGi的bundle。除了本地用于开发的读写库之外，开发者也可以从其他只读库中寻找OSGi bundle，。比如，组合使用公司内部的开源库、，公司专有的库，和经批准的第三方库等。开发者可以很容易地从一个经认证的库列表中简单地选择所需的库，并从中选取所需的组件资源，并把它们拖到Bndtools的工作区之中。
开发者将本地工作的代码放入SVN库。SVN库只存放在制件（Work-In-Progress, WIP）。Jenkins的持续不间断集成服务器不停地构建组建、，测试，并将建好的地OSGi组件模块加入共享的只读开发库中。这些组件模块可以马上通过Bndtools被所有的开发人员使用。
随着开发人员的快速开发，每天会进行多次多次的构建组建，这将会变得难以管理，对每次开发构建都增加版本号确实是没有意义的。对每天多次的开发版本进行版本更新毫无意义。由于这个原因，在开发环境中我们允许重复地使用版本号。
Figure 图 3: 发布就绪之后，开发团队在经过测试后我们可以将模块发布到只读的QA库。
Figure 图 4: 锁定当模块一旦进入QA后，在开发库中它就变成只读的了它只能被读取。任何修改或重新构建重建都会失败将会被否决。如要修改，开发人员必须增加对版本号进行递增。
Figure 图 5: 版本递增
开发人员现在可以使用Bndtools的的自动化语义版本功能来实现对版本的递增，从而确保当前的版本号能够表达出目前的WIP版本与之前版本的区别进行自动递增。根据前面文章篇幅中对语义版本规则的讨论：
在前面的文章中篇幅里我们讨论了敏捷模式成熟度模型。根据该模型对西门子的解决方案进行评估，所有高度敏捷系统所必需的特征它都满足。
正如Kirk Knoernschild在他的DEVOXX2012上的演讲“架构自上而下的架构（Architecture All the Way Down）”所讲的，敏捷运动专注于实现在敏捷开发时在社交和流程（Social and Process）的上的方面应用，但根本性的因素——－“结构性的模块化”——并没有被重视。那些想在庞大的代码库巨大的程序堆中里实现“敏捷”的人对此应该深有体会。西门子公司通过OSGi实现结构性的模块化，由此达到敏捷的目标，与在此同时也实现了社交和流程方面的敏捷开发度。
Bndtools是促成这一解决方案的关键。在此同时，西门子公司的业务需求也反过来促进和形成了了Bndtools的关键功能。在此我感谢西门子公司允许这些工作成果被Paremus和OSGi联盟所使用引用。
Bndtools基于Peter Kriens的bnd项目，Bndtools这个的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
联系客服
