使用配置管理工具进行持续集成开发.pdfVIP

Hansky Document 使用配置管理工具进行持续集成开发 1. 持续集成与现代软件开发 早期的软件开发模式是由程序员负责编写不同的模块, 在软件项目完成之前, 一次性的 把各个模块集成在一起,再进行测试。我们称这种集成方式为“big-bang” 的集成方 式。 使用该种集成方式的项目团队把软件集成安排在开发阶段的后期, 一般是应用 “瀑布式 (Cascade ) ” 开发模式。 在项目后期才开始对软件进行集成, 会为项目引入很多的未知 因素和巨大风险--程序员往往发现越来越多的 Bug 等待他们去修复。这种集成方式 很有可能会威胁到软件项目的成功。 随着市场竞争的日益激烈, 对软件产品的发布要求 越来越高、越来越频繁,这种“big-bang ”的集 成方式已经不能满足开发团队的需求。 取而代之的持续集成的开发方式 “Continuous integration ” 。 持 续集成可以有效地解决软 件开发过程中的许多问题, 可以有效的确保软件质量, 减小项目的风险, 使得软件开发 团队从容面对各种各样的变化。 持续集成在现代软件开发中扮演着非常重要的角色。 使用持续集成策略的团队, 可以发 现持续集成可以为软件开发带来如下好处: 第一: 可以尽早发现由于软件集成所带来的 Bug , 及时进行 更正。 原因在于由软件集成 而引入的 Bug 一般涉及到两个或多个程序员书写的代码,相对来说比较难于 Debug 。 如果不及早进行集成, 就不能发现该 Bug ; 一旦 集成之后, 发现该 Bug , 就要花费大量 的资源来进行 Debug 。 但是如果使用持续集成,这种 Bug 在被引入的初始阶段就能够 被发现, 程序员可以检查相对少的源代码就可以更改该 Bug , 这时所付出的代价是昀小 的。 第二: 还可以有效的避免程序员在错误的路线上越走越远, 以至于在项目后期为其付出 巨大的代价。 举例来说: Tom 和 Jerry 分别 工作在不同的模块 A 和 B 上, 其中 A 模块 需 要依赖 B 模块 中的代码。如果 B 模块中的 程序有错误,则会影响到 A 模 块。 如果 Jerry 在开发 B 模块 的过程中引入了 Bug,使得 Tom 开发 A 模块 是工作在一个错误的基础上。 如果两人的程序长时间不进行集成, 则 Tom 就会在错误的开发路线上越走越远。 持续集成可以有效的降低由于软件集成所带来的风险。 目前已经作为许多流行的软件开 发理论的基础组成部分,例如 XP ,Staging Delivery ,RUP 中 的迭代开发等等。许多软 件公司都使用 “Nightly Build ” ,或“Daily Build ” 等方式来强制程序员每天至少进行一 次集成(Microsoft 就是使 用 Daily Build 的方式进行持续集成的) 。实践已经证明,持 续集成对 于 提高软件 质 量,针对 软 件开发项 目 进行有效 的 风险管理 有 着不可替 代的 作 用。 持续集成的 意义在于使 项目随时具 有一个明确 的“昀近状 态” 。项目团 队中的成员 的 所 有工作都是建立在该状态之上的: 程序员基于该状态编写代码; 测试人员针对该状态进 行软件测试。 更为重要的是项目管理人员可以根据项目的昀新状态对项目的进度、 风险、 - 1 - Hansky Document 资源使用情况等进行有效的评估,为昀终的项目成功打下坚实的基础。 另外,现代软件开发语言(例如:C 、C++ ,Java 等)决定了持续集成的重要性。在这 些语言中, 往往是由多个源程序文件来完成某一特定的功能; 每一个源代码文件也往往 不是只服务于某一个单一系统功能。 而这些程序文件往往不是由同一个程序员编写, 如 果这些源代码文件不是经常的进行集成, 则必然在昀终的集成过程中为开发团队带来巨 大的麻烦,很有可能造成 Build Break 。2. 配置管理工具对持续集成的支持 配置管理工具 (版本控制工具) 是任何规模的开发团队中必不可少的工具之一。 使用合 适的配置管理工具可以很好的帮助开发团队进行持续集成开发。 在使用持续集成的团队 中,代码开发、源程序检入、单元测试的过程一般如下: Step1: 程序员建立本地工作区。 从版本控制工具的存储库中得到项目的所有文件。 一般来说,本地工作区和存储库具有相同的目录结构,或是存在某种特定的关联关系。 Step2: 程序员更新本地工作区,使得本地工作区中的文件都更新到昀新状态。 Step3: 程序员检出源代码文件。 Step4: 程序员更改源代码,进行单元测试。 Step5: 程序员更新本地工作区, 得到其他用户的更改, 进行单元测试。 如果有冲突发生, 需要解决冲突。 Step6: 在单元