服务热线

澳门美高梅网站

联系我们

电话:
手机:
邮箱:
地址:
当前位置:主页 > 澳门美高梅网站 >

澳门美高梅网站

多个敏捷团队之间的版本控制 - InfoQ: Software ...

作者:admin 时间:2018-12-26 20:20
本文并非专为版本控制专家所写,实际上这样的专家在本文中找不到新东西。本文是为我们这些希望进行简单、有效的协作的人所准备的。任何直接参与敏捷软件开发的人,无论他承担何种角色,都有可能对其感兴趣每个人都会用到分支和合并,而不只是配置经理。所以当一个团队成员说某个用户故事已经完成,并将故事卡移入到完成一栏中之后,客户就可以马上跑到房间中说:太好了!我们现在就上线吧!,而且团队中没有人会说:别,先等等。那我应该向何处检入我认为已经完成、但是在检入主干前需要进行验证的代码呢?当然,我可以在本机上完成测试,并直接将通过测试的代码检入到主干之中。但这还是有点吓人,我相信大家都遇到过嘿,但是它在我的机器上运行没有问题啊这样的事情。另外一个问题是好吧,我完成了今天的编码任务,现在要回家了。我该把代码检入到哪里?还没有测试过呢,所以不能检入到主干中。我想把它检入到别的地方,这样其他的团队成员就可以在其基础之上继续工作了(敏捷团队是采取代码集体所有制的,对吧?)。很好,现在我们有两个分支了。一个稳定的分支(主干)和一个稍微不那么稳定的分支(团队分支)。团队分支是红色的,表示它不太稳定;例如:这个分支通过了单元测试,但是它可能还没有完成集成测试,所以还没有稳定到可以发布的状态。好,现在团队有地方可以检入正在进行中的工作了!每个黄色的即时贴表示一项任务,也就是要完成故事需要做的一项工作。例如编辑类X,更新构建脚本,等等。每项任务通常包含一个人日的工作,每个故事通常包含3至8个人日的工作。我们的第一个团队实现了开户故事,并将代码检入到工作分支中,运行集成测试,修正一些问题,再次检入,再次运行测试,通过了!开户故事就完成了!然后将其公开发布到主干之中。如果在开户完成之前就有人准备开始存款相关的工作,可以让他先从一些相对安全和不可见的UI元素等部分开始,这些东西的变化不会影响到整个分支的可发布性。比如,存款需要开发一些新的代码以及对一些旧有代码的修改,可以先实现新的代码(新的方法、新的类、新的测试等等),而不是先去修改已有代码。如果存款需要新的GUI元素,那就让它们先不可见。等到开户故事完成而且发布到主干上之后,我们就可以开始实现存款的剩余代码了。实际上,这条规则意味着:对故事A的测试,同样包括运行之前实现的故事的全部相关回归测试。如果上传代码后,故事A没有问题,但是之前故事的测试却通不过了,这是不行的。稍等。这是不是有点不合理啊?每完成一个故事就要运行所有的回归测试?嗯,首先我没有说运行所有的回顾测试。我是说所有相关的回归测试。我们已经有了一个干净而且可发布的主干作为基础,现在只是要添加一个故事而已!这是一个很小的增量变更。如果回归测试可以自动化完成,我们就可以全部运行了。要是有需要手工完成的回归测试,那我们就要有选择性了。 最后还是归结到了对风险vs成本的权衡之上。对于每一个手动的回归测试,我们应该评估运行它的成本(比如需要多少工作量来完成测试),同时评估发现任何重要缺陷的可能性,对二者进行权衡。当然还要加入自动化该测试的成本。:o)现在我们遇到了一个有趣的问题。假定我在团队A中,而且有我们自己的工作分支。变更可能先在主干中发生,而不会先出现在我的工作分支中!为什么?恩,因为有另一个团队啊,他们每完成一个故事就会将其发布到主干中!如果我的团队(团队A)发现一个代码冲突,我们会马上解决它这是优先级最高的事情!如果我们需要团队B的帮助(或者是开发与我们发生冲突的代码的负责人),找他们过来,一起工作,把问题解决掉。重要之处在于我的团队要负责解决问题,而且我们要在自己的工作分支上(而不是在主干上)完成。所有的变更都应沿着所在的线索发展,这是一条很重要的规则!所以不能直接从团队A的工作分支向团队B的工作分支中合并代码,这会导致很多混乱。实际上,在团队A工作分支中发生的变更应该流回到主线中,再向下进入到团队B的工作分支中。