51Testing软件测试论坛

 找回密码
 (注-册)加入51Testing

QQ登录

只需一步,快速开始

测试开发精英班,通向高级软件测试工程师论坛测试积点免费获取渠道攻略20+企业级实战项目就在这里!横扫BAT,Python全栈测试开发技能大全
【113期】:Web安全测试你来问我来答!中国软件测试行业现状调查报告新鲜出炉! 【杂志】做测试行业不偏科的尖子生! 【活动】为视频UP主打CALL,互动领福利!
查看: 2960|回复: 7

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

[复制链接]

该用户从未签到

发表于 2012-5-2 19:40:32 | 显示全部楼层 |阅读模式
软件配置对敏捷开发中迭代模式的支撑

迭代开发:
在软件开发生命周期中,迭代开发模式是基于把一个大的开发周期分解为合理的小的开发周期,小的开发周期的划分可分为:
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
同时将Rel_FFR_1_1.0.0b3 部署到 UAT环境进行新一轮测试。

     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_1_1.0.0b3
                Rel_FFR_2_1.0.0b1
        Trunk

在这个点上,trunk 上面的代码主要是FFR_2的开发,
分支上的BR_ Rel_FFR_1_1.0.0b2 主要是 针对 FFR_1的代码修复
分支上的BR_FFR_3 主要是是针对FFR_3的开发工作
当Rel_FFR_2_1.0.0b1 在测试环境上发现 bug后,开发人员就回到 trunk 针对基于Rel_FFR_2_1.0.0b1 发现的bug 进行修改。 修改完成后,再针对trunk define tag 到tags 目录,假定Rel_FFR_2_1.0.0b2,  然后部署到 测试环境进行测试。

    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_1_1.0.0b3
                Rel_FFR_2_1.0.0b1
                Rel_FFR_2_1.0.0b2
        Trunk

当Rel_FFR_1_1.0.0b3 在UAT 上完成测试后,配置管理人员将关闭BR_Rel_FFR_1_1.0.0b2 分支,同时将上面的修改merge到 trunk。

    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_1_1.0.0b3
                Rel_FFR_2_1.0.0b1
                Rel_FFR_2_1.0.0b2
        Trunk

剩下的工作就是对以上步骤的循环,最后完成整个 FFR_1,FFR_2,FFR_3,FFR_4,FFR_5的开发。
这个过程是一个 同步迭代的过程。

最后,对这个过程有需要完善和修改的地方,欢迎补充。
QQ:827212416
回复

使用道具 举报

该用户从未签到

发表于 2012-5-21 11:01:40 | 显示全部楼层
很清晰
回复 支持 反对

使用道具 举报

该用户从未签到

发表于 2012-5-21 11:01:46 | 显示全部楼层
很清晰
回复 支持 反对

使用道具 举报

该用户从未签到

发表于 2012-5-21 11:01:57 | 显示全部楼层
很清晰
回复 支持 反对

使用道具 举报

该用户从未签到

发表于 2012-5-21 11:11:33 | 显示全部楼层
很清晰
回复 支持 反对

使用道具 举报

该用户从未签到

发表于 2012-5-24 11:08:51 | 显示全部楼层
很清晰,也有点复杂。
回复 支持 反对

使用道具 举报

该用户从未签到

发表于 2012-6-2 23:20:40 | 显示全部楼层
感觉有点复杂了
回复 支持 反对

使用道具 举报

该用户从未签到

发表于 2012-7-18 16:20:28 | 显示全部楼层
有点复杂,但很有用
回复 支持 反对

使用道具 举报

本版积分规则

关闭

站长推荐上一条 /3 下一条

小黑屋|手机版|Archiver|51Testing软件测试网 ( 沪ICP备05003035号 关于我们

GMT+8, 2020-7-11 15:56 , Processed in 0.073251 second(s), 28 queries .

Powered by Discuz! X3.2

© 2001-2020 Comsenz Inc.

快速回复 返回顶部 返回列表