软件配置对敏捷开发中迭代模式的支撑

发表于:2016-3-29 11:11

字体: | 上一篇 | 下一篇 | 我要投稿

 作者:cd_sz2000    来源:51Testing软件测试网论坛

  迭代开发:
  在软件开发生命周期中,迭代开发模式是基于把一个大的开发周期分解为合理的小的开发周期,小的开发周期的划分可分为:
  1,按照功能的需求划分为不通 的小的开发周期
  2,按照交付的需求先后顺序 划分为不通的小的开发周期。
  前者 笔者认为适合产品的研发划分,比如开发一个产品。
  后者适合为客户开发项目来划分,比如为某银行开发一套系统。
  在这样的开发模式下,配置管理的合理规划可以很方便的让开发人员,配置人员,项目经理,测试人员有序的组织工作
  怎样合理的规划配置项呢?
  笔者在这里假设一个工作场景。
  公司的配置管理基于svn,为某银行开发一套内部系统。该系统大致有30个需求。
  按照这30个需求的功能已经交付的优先级,拆分为5个小项目,定义为
  FFR_1.
  FFR_2
  FFR_3
  FFR_4
  FFR_5
  其中,交付序列为 1,2,3,4,5 来划分。
  准备 测试环境,UAT环境,以及客户的生产环境。
  SVN的规划,我们可以定义为:
  FFR
  Branches
  BR_FFR_2
  BR_FFR_3
  BR_FFR_4
  BR_FFR_5
  Tags
  Trunk
  看到这里,大家觉得奇怪,FFR_1的代码呢? 因为 FFR_1的代码 我们是需要最先交付的,所以 FFR_1的代码, 我们就 存放到 trunk 下面。
  在开发活动中, 我们的开发人员按照开发计划,首先完成FFR_1阶段的开发,所有的提交都在 trunk 下面进行,当 FFR_1 的代码开发完成以后,配置管理员可以对trunk define tag 到 Tags 目录,假定为Rel_FFR_1_1.0.0b1
  Branches
  BR_FFR_2
  BR_FFR_3
  BR_FFR_4
  BR_FFR_5
  Tags
  Rel_FFR_1_1.0.0b1
  Trunk
  Define Rel_FFR_1_1.0.0b1   后,再把Rel_FFR_1_1.0.0b1  部署到测试环境,测试人员开始在上面测试。
  同时,配置管理员 基于Rel_FFR_1_1.0.0b1   把代码 copy 到 BR_FFR_2 的目录下面,开发人员就开始在这段时间,进行 FFR_2 的需求的开发工作,相关的FFR_2的代码提交到 branches 的BR_FFR_2下。
  在这个过程中, 测试人员在测试环境上发现了Rel_FFR_1_1.0.0b1   版本的 bug, 开发人员就回到 trunk上基于Rel_FFR_1_1.0.0b1   发现的bug进行修复。这个过程结束后,配置管理员再基于新的修改 对trunk define tag 到tags 目录 ,假定为Rel_FFR_1_1.0.0b2
  Branches
  BR_FFR_2
  BR_FFR_3
  BR_FFR_4
  BR_FFR_5
  Tags
  Rel_FFR_1_1.0.0b1
  Rel_FFR_1_1.0.0b2
  Trunk
  Define Rel_FFR_1_1.0.0b2  后,再把Rel_FFR_1_1.0.0b2  部署到测试环境,测试人员开始在上面进行新一轮测试。 开发人员这个时候继续回到branches下的BR_FFR_2目录进行开发工作。
  假定经过新一轮测试后,测试人员没有在测试环境上发现bug,这个时候,按照计划,我们就可以把Rel_FFR_1_1.0.0b2 部署到 UAT环境 进行验收测试。
  在这个时候,开发人员需要对branches  中BR_FFR_2 代码 merge 到 trunk,然后回到 trunk 上,继续基于FFR_2的需求进行开发。 同时,配置管理人员将 BR_FFR_2 分支 关闭。
  Branches
  BR_FFR_3
  BR_FFR_4
  BR_FFR_5
  Tags
  Rel_FFR_1_1.0.0b1
  Rel_FFR_1_1.0.0b2
  Trunk
  当 FFR_2的需求开发完成以后,配置管理人员再对 trunk define tag 到 tags 目录,假定为
  REL_FFR_2_1.0.0b1
  Branches
  BR_FFR_3
  BR_FFR_4
  BR_FFR_5
  Tags
  Rel_FFR_1_1.0.0b1
  Rel_FFR_1_1.0.0b2
  Rel_FFR_2_1.0.0b1
  Trunk
  Define Rel_FFR_2_1.0.0b1   后,再把Rel_FFR_2_1.0.0b1  部署到测试环境,测试人员开始在上面测试。
  同时,配置管理员 基于Rel_FFR_2_1.0.0b1   把代码 copy 到 BR_FFR_3 的目录下面,开发人员就开始在这段时间,进行 FFR_3 的需求的开发工作,相关的FFR_3的代码提交到 branches 的BR_FFR_3下。
  假定在这个过程中,  客户在UAT 环境发现了基于Rel_FFR_1_1.0.0b2 的bug, 这个时候,配置管理员就需要对 tags的Rel_FFR_1_1.0.0b2  建立 braches,来维护Rel_FFR_1_1.0.0b2 的bug 修复
  Branches
  BR_FFR_3
  BR_FFR_4
  BR_FFR_5
  BR_ Rel_FFR_1_1.0.0b2
  Tags
  Rel_FFR_1_1.0.0b1
  Rel_FFR_1_1.0.0b2
  Rel_FFR_2_1.0.0b1
  Trunk
  所有的基于Rel_FFR_1_1.0.0b2 的开发将提交到 branches 下的BR_ Rel_FFR_1_1.0.0b2。 当修改完成后,对BR_ Rel_FFR_1_1.0.0b2 define tag 到 tags 目录,假定为   Rel_FFR_1_1.0.0b3
21/212>
《2023软件测试行业现状调查报告》独家发布~

关注51Testing

联系我们

快捷面板 站点地图 联系我们 广告服务 关于我们 站长统计 发展历程

法律顾问:上海兰迪律师事务所 项棋律师
版权所有 上海博为峰软件技术股份有限公司 Copyright©51testing.com 2003-2024
投诉及意见反馈:webmaster@51testing.com; 业务联系:service@51testing.com 021-64471599-8017

沪ICP备05003035号

沪公网安备 31010102002173号