敏捷与结构性模块化(三)

2013-12-27  来源:本站原创  分类:管理  人气:0 

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

第三篇文章基于标题为“现实世界的挑战:基于OSGi/Bndtools的开发、发布和版本控制的工作流程”(Workflow for Development, Release and Versioning with OSGi / Bndtools: Real World Challengeshttp://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库。

相关文章
  • 敏捷与结构性模块化(三) 2013-12-27

    该系列的第一篇文章介绍了结构性模块化和敏捷的根本性的关系,在第二篇中我们了解到如何使用OSGi实现高度敏捷和高度可维护的软件系统. 第三篇文章基于标题为"现实世界的挑战:基于OSGi/Bndtools的开发.发布和版本控制的工作流程"(Workflow for Development, Release and Versioning with OSGi / Bndtools: Real World Challenges,http://www.osgi.org/CommunityEvent

  • 敏捷与结构性模块化(一) 2014-05-21

    1 简介 敏捷开发方法论日益流行,然而大多数"敏捷"专家和分析师都在孤立地讨论敏捷,也就是说忽视了系统"结构"(Kirk Knoernschild是一个例外,他编写了一本名为<Java Application Architecture>的图书阐述这一理念).考虑到"敏捷"是基础实体的一个重要特性或属性,那么,这种疏忽令人感到很惊讶.一个实体要具有"敏捷"的特性,它必须具有高度的结构性模块化(structural m

  • 敏捷与结构性模块化(二) 2015-03-27

    在上一篇文章中,介绍了结构性模块化与敏捷之间的关系,在这个系列的第二篇文章中,我们将会研讨OSGi™,在实现Java™的结构性模块化方面,OSGi扮演了核心的角色:OSGi与流行的敏捷方法论之间存在着自然的联系. 1 但我们已经实现了模块化! 绝大多数开发人员都同意程序应该模块化.尽管在面向对象的程序设计出现的早期,逻辑性模块化的要求就被迅速满足了(见http://en.wikipedia.org/wiki/Design_Patterns), 但是软件行业花费了很长的时间才理解结构性模块化的重要

  • 2011年度敏捷软件开发调研结果发布 2015-04-30

    最近,VersionOne揭晓了2011年度敏捷软件开发调研结果,再一次向大家展示了敏捷应用和发展趋势的第一手资料. 今年,我们进一步确信敏捷并非一时风潮.我们过半的调查对象坦言他们已经亲身实践敏捷超过两年了,并且三分之一的人把敏捷从一家公司带到了另一家.大约有三分之二的调查对象谈到,他们公司的项目有超过半数在使用敏捷方法,有三个以上团队实施了敏捷实践. Scrum依然是敏捷方法流行榜中当之为愧的状元,52%的受访者采用了Scrum(2010年则是58%). 52% Scrum 14% Scru

  • 创建适于敏捷的组织文化 2014-01-29

    Greg Smith在一篇文章(内容源自他即将出版的新书<Becoming Agile>)中提出观点认为,要全面深入并务实地过渡到敏捷模式,关注文化变化的重要性不亚于对流程改变的关注 . 正如众多讲述各种敏捷方法论(尤其是极限编程和Scrum)的好文章中明确指出的,真正的敏捷来源于团队在正确的价值观.原则.态度和行为上达成一致的能力,却没有强调整个组织的的转化.Smith提到,这将意味着在公司的文化方面: 过渡到敏捷模式不仅仅是改变流程,它还需要文化方面的转变.对于大多数的公司来说,改变文化是

  • 微观SOA:服务设计原则及其实践方式(下篇) 2014-03-30

    在上一篇文章中,我说到SOA是一个特别大的话题,不但没有绝对统一的原则,而且很多原则本身的内容也具备相当模糊性和宽泛性.虽然我们可以说SOA ≈ 模块化开发 + 分布式计算,但由于其原则的模糊性,我们仍然很难说什么应用是绝对符合SOA的,只能识别出哪些是不符合SOA的. 本篇将对8种可操作的服务设计原则进行细化的分析,作为SOA实践的参考. 服务设计原则1:优化远程调用 这里的远程调用特指RPC(Remote Procedure Call).当然更面向对象的说法应该是远程方法调用或者远程服务调用

  • 采访Vasco Duarte和Jason Little: 来自Happy Melly Express的 2014-06-20

    来如Happy Melly的Vasco Duarte表示,变革推动者们需要有"持续不断的高品质内容来协助推进他们的工作".InfoQ对他进行采访,讨论了他所创办的一项新兴出版业务,该业务旨在将作者和他们的读者以可持续的方式联系在一起:同时也采访了Jason Little,即将出版的<精益变革管理>的作者. Happy Melly今年年初开始启动.Lisette Sutherland在Happy Melly: A Business Network to Help People

  • 如何坚持TDD:使用者出现的问题以及解决方案 2014-06-24

    我们组织里曾有许多团队努力采用测试驱动开发(TDD)[1].偶尔会有一两个开发者成功,但是大多数都失败了.为了更好地找出原因,我调查了团队 的一些成员,发现即使经过了课堂培训,还有更多的事情需要做.虽然这里介绍的问题和想法只适用于中大型的公司,但理解这一点能够帮我们在组织中更好地引入 TDD. 我对组员(他们全都接受过培训)的调查显示,以下问题影响了他们: 由于经验不足,大家发现自己直接TDD比较困难. TDD培训的例子比实际应用简单得多. 需要更多的时间来实验和尝试,不要有赶紧发布软件的压力.

  • 双面SOA:商业模式不成熟与诱人的愿景 2013-10-30

    SOA不是一个新概念.早在1996年,Gartner就提出了SOA的理念.2002年,Gartner提出SOA是"现代应用开发领域最重要的课题",并预计到2008年,SOA将成为占有绝对优势的软件工程实践方法; 2010年,采用SOA体系的企业将占80%. 这或许就是近年来SOA火遍IT业的原因之一.普元.甲骨文.IBM.用友.金蝶等国内外软件企业,纷纷高举SOA大旗,用SOA概念包装已有或即将推出的各种产品和解决方案,备战软件市场. 2007年,这些软件企业开始推出了一些实施方案,并

  • 抛砖引玉:Session和Cookie在WEB开发中的最佳实践 2012-10-26

    从我上个转帖:Session与Cookie的区别和联系 可以看出这两个会话工具的异同点,但如何灵活应用这两个工具才是我们关注的重点! 下面我们通过现实网络中的例子来分别说明Session和Cookie在WEB开发中的最佳实践: 1.记住登录信息 当我们注册一个网站后,下次再次浏览的时候会发现系统已经自动帮我们登录进去了(至少可以记住我们的用户名吧),省去了手动登录的环节,很神奇吧,但这到底是如何实现的呢?像这样可以持久的驻留在客户端处只能是Cookie! Cookie的内容主要包括:名字.值.过

  • Java程序员的推荐阅读书籍 2014-11-19

    作为Java程序员来说,最痛苦的事情莫过于可以选择的范围太广,可以读的书太多,往往容易无所适从.我想就我自己读过的技术书籍中挑选出来一些,按照学习的先后顺序,推荐给大家,特别是那些想不断提高自己技术水平的Java程序员们. 一.Java编程入门类 对于没有Java编程经验的程序员要入门,随便读什么入门书籍都一样,这个阶段需要你快速的掌握Java基础语法和基本用法,宗旨就是"囫囵吞枣不求甚解",先对Java熟悉起来再说.用很短的时间快速过一遍Java语法,连懵带猜多写写代码,要"

  • 敏捷开发三次迭代(Iteration Three) 2015-03-30

    三次迭代(Iteration Three)是敏捷项目开发管理周期中的一个阶段,到达这个阶段时,项目已经成功的在某些问题上调整过2次. 起初,一次小规模的需求收集.开发.测试和用户反馈,形成一次完整的迭代,之后,基于第一次中获得的信息,第二次迭代启动.这阶段通常会在一个较短的时间段内完成,例如一个月. 第一次迭代只是一个产品的从无到有的过程,第二次迭代是把获得的用户反馈反映到开发过程中,结果是把根据反馈修改的产品展示给用户. 在三次迭代中,用户已经感觉到了他们提出的需求已经分次的在有规律的周期里实

  • 三项执行层的支持,支撑起敏捷实施的天空 2013-12-15

    除了决定要用敏捷并为培训买单之外,接下来执行层的工作还有不少.要想让这个改造成功,执行层必须要一直提供支持.Esther Derby从在这些支持中选出了三项她觉得最重要的工作. 她在Agile Journal写了一篇文章:三项执行层的支持,支撑起敏捷实施的天空,为读者提供了一些帮助敏捷实施成功的方法.下面是对Esther观点的一些概要描述: "有权利说不" 拒绝人们回退到旧方法的请求,从而展示你对这项改造的决心: 一旦有了新方法.新流程.新政策,人们就会想举出不适用的情况,让他们可以继

  • 中国敏捷实践中的误区(三)误区和改进 2014-08-14

    三个主要误区 第一个是重视流程忽视人.敏捷宣言开明宗义指出"人和沟通胜过过程与工具".但是仍然有很多企业试图通过创造一个完美的流程来实施敏捷.不可否认,合理的流程对于提高团队效率有一定的作用,但是企业真正要从敏捷改进中获益必须落实到人的改变上来. 第二个是重视管理轻视工程.很多团队将敏捷等同于开开站会.做做迭代.搞搞回顾.到头来,一切流于形式.敏捷说到底是对于软件工艺性的认识回归,那么持续集成.自动化测试.设计.重构这些手艺是绕不开的.不从这些根本的手艺上解决问题,各种眼花缭乱的沟通手

  • 对话Martin Fowler与Roy Singham--第三届"敏捷中国"技术大会专访 2014-09-09

    2008年6月21日,由Thought-Works与CSDN合办的第三届"敏捷中国"技术大会在北京丽亭华苑酒店召开.在以"精益软件思维"为主题的本届大会上,敏捷宣言的缔造者之一.ThoughtWorks首席科学家Martin Fowler再度来华,与多位ThoughtWorks公司内外的技术专家一同为开发者带来了精彩的演讲主题. 就领域专用语言以及Thought-Works的发展愿景,本刊分别对ThoughtWorks首席科学家Martin Fowler和Thoug

  • [敏捷JAVA读书笔记-java基础部分] 第三章 2010-05-11

    一.字符串 Java中字符串是对象.字符串是不可更改的. String str = "abc": String str1 = new String("abc"); 推荐使用第一种方式,因为第一种方式只创建了一个对象. 虚拟机首先创建一个Sting对象的引用,然后到堆区查找,有没有String对象"abc",如果有就将这个String对象的引用指向"abc". 第二种方式一共创建了两个对象:虚拟机首先创建一个"abc&

  • 敏捷(三)如何让每个人都能上车 2013-03-15

    很多项目甚至在驶出初始街区前就被扼杀了.多数原因如下: 1.他们没有提出正确的问题. 2.他们没有勇气提出尖锐的问题. 个人在补充一点,他们更没有勇气去面对那些尖锐的问题. 一.多数项目是如何被扼杀的 在于我们在开始阶段没有协调一致(这也很自然).关键在于还没等的有人都上车呢,我们项目已经启动了. 我们更可怕的是,项目在向前跑,一些连这辆车开向哪里,怎么开都没弄清楚的人在半道上强行上车,更可悲的是上了车还要乱操作. 那么我们需要完成下列一些任务: 1.将项目的目标.大气层景和背景传达给团队成员,

  • Javascript模块化编程(三)require.js的用法及功能介绍 2013-11-21

    这个系列的第一部分和第二部分,介绍了Javascript模块原型和理论概念,今天介绍如何将它们用于实战.我采用的是一个非常流行的库require.js感兴趣的朋友可以了解下啊 这个系列的第一部分和第二部分,介绍了Javascript模块原型和理论概念,今天介绍如何将它们用于实战. 我采用的是一个非常流行的库require.js. 一.为什么要用require.js? 最早的时候,所有Javascript代码都写在一个文件里面,只要加载这一个文件就够了.后来,代码越来越多,一个文件不够了,必须分成

  • Javascript模块化编程(三):require.js的用法 2014-09-25

    作者: 阮一峰 这个系列的第一部分和第二部分,介绍了Javascript模块原型和理论概念,今天介绍如何将它们用于实战. 我采用的是一个非常流行的库require.js. 一.为什么要用require.js? 最早的时候,所有Javascript代码都写在一个文件里面,只要加载这一个文件就够了.后来,代码越来越多,一个文件不够了,必须分成多个文件,依次加载.下面的网页代码,相信很多人都见过. <script src="1.js"></script> <sc

  • 敏捷实施中的学习与阈限 2013-11-08

    给读者的话:如果你是首次接触开放式敏捷实施的一系列文章,你可以先回过头去看看这一系列文章的第一部分.第二部分和第三部分.上篇文章(第三部分)描述了阈限(Liminality)的概念,在阅读本文之前,先读一读这些概念是非常有必要的. 阈限状态中的稳定性 阈限是令人不安的,并且还会产生压力.关于开放式敏捷实施的一个设想是,在典型组织里引入敏捷会产生组织级的阈限.如果使用过渡仪式的方式来处理这个阈限,那么创造一个快速而持久的敏捷实施还是有可能的. 开放式敏捷实施背后的核心概念就是认清和解决阈限问题可以