现在的位置: 首页 > 综合 > 正文

敏捷软件开发基础: 持续集成环境的构建

2013年08月13日 ⁄ 综合 ⁄ 共 2823字 ⁄ 字号 评论关闭

从技术层面上来讲,"持续集成"的含义是指开发团队中的每个成员都尽量频繁地把他们所做的工作更改合入到源码库中,并且还要验证新合入的变化没有造成任何破坏。本文中,作者将介绍如何构建持续集成所需要的环境。

敏捷意味着什么

Agile可以说是近几年来软件工程界最"热"的一个单词,关于它的文章、书籍、讨论不计其数。尽管如此,却仍有大量的从业者对Agile存有误解和困惑。Agile到底意味着什么呢?仅仅是一些漂亮、时髦的宣传吗?到底怎样才算是Agile呢?做到了Agile能为软件开发团队带来什么好处呢?类似的问题还有很多。

Agile其实根本不是一个什么新鲜、时髦的东西,它已经存在了数十年之久了。在这数十年中,那些取得成功的软件开发团队无一不是敏捷开发团队。他们在自己的软件开发过程中大量应用了Agile的思想,只是没有把他们的工作方式、价值观念以及指导思想正式表述出来而已。到了2001年初,这种状况得到了改善,一批在软件开发领域奋战了数十年的领袖和开发大师们(尤其是面向对象社团和Smalltalk社团的领袖)再也无法容忍由于对软件本身的误解以及官僚主义所造成的软件开发方面的混乱,他们把自己数十年来对软件以及团队软件开发的理解和经验总结成了一份"Agile Manifesto",以呼吁软件从业者们应该以怎样的态度来开发和认识软件。Agile的所有思想基础和价值取向全都包含在这份宣言之中。

但是这份宣言对于大多数人来讲,仍然显得有些缺乏可实践性。作为一个软件开发团队,我们可以接受敏捷宣言中的价值观念,但是怎样做才是Agile呢???换句话说,Agile如何落实到团队每天的开发工作中呢?几乎每个试图尝试敏捷软件开发的团队,都曾经被这个问题所困扰过。从团队日常的开发活动的角度来看,Agile就是:
"Short Cycles that are test-driven and feedback-driven, yielding constant improvement."

其中,short cycle是核心。整个软件开发活动应该被划分成一系列短的迭代过程,每个迭代完成一定数目的features。迭代的周期应该尽量得短。更为重要的是,迭代应该是由测试和反馈驱动(TDD和沟通)的。只有这样,我们才能为持续地改进(通过refactoring)提供一个良好的基础和安全网络。请注意,这个过程和一般所说的code-and-fix的本质不同在于:这里的每个迭代周期产出的都是一个经过验证的可用产品,只是可能功能不全,并且这是一个有意识的、持续的基于反馈的改进过程,而不是简单的fix。其实所有成功的项目开发活动都是接近这个标准的,只不过Agile把它放在了最为重要的位置上。

要想有效地达到上面所说的效果,除了需要一些技术方面的技能外(比如:重构技能,TDD技能等)。我们还需要一个能够对上面这种形式的活动进行有效支撑的环境,这个环境应该是所有想取得成功的项目的基础,也就是一个持续集成环境。持续集成为有效地达到Agile提供了基础。那么什么是持续集成呢?


回页首

什么是持续集成

从技术层面上来讲,"持续集成"的含义是指开发团队中的每个成员都尽量频繁地把他们所做的工作更改合入到源码库中,并且还要验证新合入的变化没有造成任何破坏。这里的库指的是受版本控制工具(比如:ClearCase或者CVS)管理的软件源代码储存地。这里的频繁程度和团队所开发的软件类型有关,但是一般来说频度应该不大于1个小时。

请注意,持续集成的概念和大家以前曾经听说过的"每日构建"和"每晚构建"的概念有所不同。按照Martin Fowler的话来讲,这个不同主要体现在三个方面:

  • 持续集成在一天之中要频繁地发生,而每晚构建却每天发生一次。
  • 每晚构建的目的是为了产生一个稳定的可用发布,而持续集成除了达成这个目标之外,还对集成的成功与否提供了快速的反馈。
  • 每晚构建并没有规定开发者应该check in的频度,而持续集成为了达到快速反馈的目的,鼓励高频度的check in。

大家可以看出,持续集成的高频度check in和快速提供反馈的特性为有效地达到Agile提供了一个坚实的技术基础。可以这么说,如果没有一个好的持续集成环境作为基础,要想高效地进行团队软件开发几乎是不可能的。那么,如何构建起一个这样的环境呢?在本文的后面,我将给出了一个详细的教程为你提供一步一步的详细指导,但是在这之前,我们先来了解一下构建一个有效的持续集成环境所需要的工具。


回页首

持续集成工具介绍

高效地进行持续集成活动的一条有效途径就是自动化,这一点不用说大家也都知道。那么如何才能实现自动化呢?有没有一些现成的工具可以直接拿来使用呢?答案是肯定的。除了那些价格昂贵的商用工具软件外,还有很多简单易用并且非常有效的Open Source免费软件可用。对于这些开源的免费软件,大家大可放心使用,因为很多非常优秀的开源软件都是在这些工具软件所构建的持续集成环境中开发出来的。下面我对几个比较重要的开源工具进行简单的介绍。

  • Eclipse:Eclipse是一个开源的IDE,是为程序员量身定做的。它最大的特点在于它借鉴了Smalltalk开发环境的思想,可以把自己内部的工作原理通过某种方式展现在使用者面前,使用者只要遵循一些原则就可以根据自己的需要更改这个开发环境。在Eclipse中,这种机制是通过plug-in的方式运作的。通过这种方式,使用者可以方便地把开发过程中常用的工具无缝地集成起来,并以便于自己使用的方式呈现出来。比如:可以方便地把refactoring、JUNIT和CVS等工具集成到Eclipse这个统一的开发平台中来,为持续集成提供一个良好的操作平台。
  • CVS:CVS是一个开源的版本控制工具软件,和一些价格昂贵的同类商业软件相比,它提供的功能可谓不多,但是这些功能对于大多数的软件开发团队来说已经足够了。CVS为开发团队提供了一个项目范围内的时间机器。通过它,团队可以方便、准确地获取项目在指定时间的状况。不仅如此,CVS还提供有tag和branch的功能,这些功能为团队进行多分支并行开发提供了基础,并且不用担心工作成果的丢失问题。
  • CruiseControl:CruiseControl是一个持续构建过程框架,并且它对外提供了用于扩展的机制。使用CruiseControl的plugins机制,用户可以方便地将各种需要的源码控制工具和构建工具集成起来,并且可以针对当前和历史构建状态提供诸如email通知、Web显示等对外接口。正是通过这个工具,实现了持续集成的可定制化和自动化。

好了,工具的介绍就到这里,下面就可是我们的持续集成环境搭建之旅。本文不对Refactoring技术、Eclipse、JUnit以及CVS本身的知识做太多的介绍,主要集中在如何把这些工具集成起来构建一个持续集成环境上面,相关的基本知识读者可以自行参考相关的书籍。

抱歉!评论已关闭.