软件测试的配置管理：多个敏捷团队之间的版本控制
网上看到的关于测试的配置管理，有兴趣大家一起探讨下。
文章内容简介：
如果我们有多个敏捷团队在同一个代码库上工作时，如何将彼此之间代码互相冲突的风险最小化？如何确保每个迭代结束时拥有一个干净的、可发布的软件版本？本文讲述了关于如何在敏捷的环境中与多个团队共同进行版本控制工作的实例——这正是我们在《Scrum and XP from the Trenches》中描述的公司所采纳的方式。
本文并非专为版本控制专家所写，实际上这样的专家在本文中找不到新东西。本文是为我们这些希望进行简单、有效的协作的人所准备的。任何直接参与敏捷软件开发的人，无论他承担何种角色，都有可能对其感兴趣——每个人都会用到分支和合并，而不只是配置经理。
介绍
从工作分支公开发布（publish）至主干
如果团队同时在实现多个故事该怎么办？
完成包括回归测试在内的工作
分叉代码（合并冲突）
多个团队——如果其他团队同时向主干中发布代码该怎么办？
发布分支
模型的变种
“完成”的定义不必一定是“可发布的”。
主干不必是主线
团队不一定必须有自己的分支
不必每次都创建一个全新的发布分支
不必在每个sprint结束后都进行发布
不必针对每个故事都运行回归测试
附件
-
软件测试的配置管理.rar
(247.27 KB, 2008-11-21 19:06)
-
关于附件奖励,
下载次数 29,
使用阶层: 通用
, 推荐星级: ★★★★ , 出售价格: 4 金钱 , 你的购买价格: 4 金钱,【快速获取积分】
搜索更多相关主题的帖子:
软件测试 版本控制 团队 管理
