软件测试的配置管理：多个敏捷团队之间的版本控制_敏捷开发_领测软件测试网
软件测试的配置管理：多个敏捷团队之间的版本控制
发表于：来源：作者：点击数：
如果我们有多个 敏捷 团队在同一个代码库上 工作 时，如何将彼此之间代码互相冲突的风险最小化？如何确保每个迭代结束时拥有一个干净的、可发布的软件版本？本文讲述了关于如何在敏捷的环境中与多个团队共同进行 版本控制 工作的实例----这正是我们在《Scrum
如果我们有多个团队在同一个代码库上工作时，如何将彼此之间代码互相冲突的风险最小化？如何确保每个迭代结束时拥有一个干净的、可发布的软件版本？本文讲述了关于如何在敏捷的环境中与多个团队共同进行工作的实例----这正是我们在《Scrum and XP from the Trenches》中描述的公司所采纳的方式。
&&&&&&& 本文并非专为版本控制专家所写，实际上这样的专家在本文中找不到新东西。本文是为我们这些希望进行简单、有效的协作的人所准备的。任何直接参与敏捷软件的人，无论他承担何种角色，都有可能对其感兴趣----每个人都会用到分支和合并，而不只是配置经理。
介绍&&&&&&& 本文讲述了关于如何在敏捷的环境中与多个团队共同进行版本控制工作的实例。我假定你已经熟悉了Scrum的基本元素、XP方法和任务板。这些方式不是我发明的，它们是基于“主线（mainline）模型”或“稳定主干（stable trunk）模式”。想阅读更多信息请查看引用部分。
&&&&&&& 撰写本文，是因为我一直在遇到需要类似内容的团队。许多团队在理解了模型之后，似乎非常喜欢这些模型。它也正是我们在《Scrum and XP from the Trenches》中描述的公司所采纳的方式。它真的可以帮助我们以更敏捷的方式来开发和发布软件。通过以易于阅读的方式来描述模型，也许我不再需要反复在白板前做解释了。:o)
&&&&&&& 注意这只是众多模式中的一种，不是“银弹“。如果你决定采用该模型，也许你需要做出一些变更来适应你自己的特定上下文。
目标&&&&&&& 在多个团队构成的敏捷环境中，版本控制模型必须达成以下目标：
快速失败代码冲突和集成问题应该可以被迅速发现。经常修复小问题要胜过不常修复大问题。一直可发布即使经历了一个混乱的Sprint，也要保证至少有些可以发布的内容。简单所有的团队成员每天都会使用这些模式，所以相关规则和程序必须要简单明了。单页总结（对于挂在墙上的内容）如果该图让你觉得很迷惑，别着急，阅读本文即可。如果其中的理念对你来说很明显，读读本文也无妨。
原文转自：
评论列表（网友评论仅供网友表达个人看法，并不表明本站同意其观点或证实其描述）热门日志推荐
人人最热标签
分享这篇日志的人常去
北京千橡网景科技发展有限公司：
文网文[号??京公网安备号?甲测资字
文化部监督电子邮箱：wlwh@??
文明办网文明上网举报***： 举报邮箱：&&&&&&&&&&&&
请输入手机号，完成注册
请输入验证码
密码必须由6-20个字符组成
下载人人客户端
品评校花校草，体验校园广场小团队管理工具选择：不需要大而全
发表于 14:19|
作者赵九州
摘要：该如何选择小团队管理工具？摩博科技技术副总监赵九州认为最该注重实效，不需要大而全。而满足所有情景的工具是不存在的。选择团队管理工具主要应考虑功能、速度、好用这三个因素，最终落实在团队成员使用率上。
今天讨论小技术团队管理工具，小团队工具选择的话，应该注重实效。自己用么，要实在点的，轻便好用，不需要大而全。具体怎么选，真的要结合团队情况，没有最好，只有适不适合，满足所有情景的工具是不存在的。摩博科技技术副总监 赵九州先抛个砖吧，我们认为选择团队管理工具主要应考虑功能、速度、好用这三个因素，最终落实在团队成员使用率上。首先功能不必多说，能满足或者缺点但能忍，都成。其次，着重强调一下速度。相对于功能，速度可能常常被忽视了。我觉得，作为经常使用的生产工具，速度甚至比功能更重要。操作的反馈一定要及时，一个很慢的工具能毁掉人的心情，比如上传一个文档，每秒十几KB跟几百KB给人的感觉完全是不一样的。记住，这是要天天都用的东西。再次，功能要“好用”。比如说任务列表，很多工具都有，但真天天打交道用起来你就会发现差别真的很大，有的用着憋屈，有的就是爽。看上去能用真的远远不够。最后，团队成员的使用率。团队管理工具，必须要有成员参与的，没人用，东西再好也没意义。上面三点都是为了保证工具更容易被人接受，除了这些，团队成员的接受程度、学习能力也是重要考量因素，建议还是让中等水平的成员小范围试试再做决定。除了上面这些核心因素，我们还有很多要选择：自己搭建还是使用网络服务，服务的话用国内还是国外的，付费还是免费？自己搭建还是使用网络服务，自己搭建有不少选择，GitLab、Redmine、trace、JIRA，国内的蝉道等。如果能对网络服务的安全性放心，剩下的主要是成本考虑吧。团队小的话用服务也不错，服务靠谱的话肯定省心省力，不怕折腾出什么问题。当初自己搭建 GitLab 的时候没少折腾，遇到过包括官方***文档写错了在内各种各样的问题，所以到现在一直没敢去升级……国外服务的话，主要问题是访问速度没保证。Google
Doc 绝对是文档协作的神器，但放在中国就是不好用。扯上中国特殊的国情，“Copy2China”真是太普遍了，于是我们有了很多选择：正如 Tower 对于 Basecamp，Worktile 对 Trello，GitCafe 对 GitHub……付费还是免费？“免费的才是最贵的”，用一个网络服务尤其是国内服务，最担心一件事的是哪天关门了，付费的话至少能心安点----咱这点钱总能多维持服务器运行一段时间吧。而且，一个月一两百顶天了，真心不贵。下面分享一下我对一些工具的看法。GitHub 和 GitLabGitHub 大名鼎鼎不用介绍了，没有关门的风险，但网络抽风或被盾的概率太高了。GitLab 相当于克隆的 GitHub 软件，如果想搭建一个内部的 git 仓库，推荐用 GitLab。团队管理方面，两者提供了问题列表、wiki、Readme文档作为支持，到处都用 Markdown。用 Markdown 写文档优点是简便、利于版本控制，但问题也不少：插图痛苦；依赖后台渲染；除了 Web 圈外，掌握的人还是不够多；作为内部技术文档撰写工具尚可，但往非技术部门传阅就不方便了，很多时候还是要 Office 格式的。除了 Markdown 的问题外，问题列表也就是个简单的任务列表，拿来管进度可不好用，附件的处理也一般，主要还是长于代码方面的管理。Tower表扬一下彩程设计，这是一个很用心的产品，小团队应该试一试，主要功能并不多----主题讨论、任务列表、文档、日历，但是用起来非常顺手，有很多超出预期的地方。上传附件真的是很爽，Ctrl+V 直接粘贴截图，到处都可以拖拽上传，一边写文档一边后台上传。流畅的上传下载速度，自动保存。它的文档编辑器可比一般的通用 HTML 编辑器好用多了，忘掉乱七八糟的标签吧。文档版本功能好用，支持图片。协作方面，当有人正在编辑文档时会锁定文档，防止他人同时编辑，可以看到其他人都在做什么。Redmine个人觉得 Redmine 对于小团队太重了，除非你的项目工期较长、规模较大，否则很多东西都是用不到的。交互什么的不能说差，真的一般。最后举个例子。我们团队一开始要写周报，等到周末回忆这周做了什么肯定记不起来，所以我一开始用记事本记，后来试了下 TeamCola 觉得还挺好用的。正好小组记录的情况也不好，就先小范围推行了。小范围推行前，因为
TeamCola 当时已经没有更新迹象了，我怕哪天关门，就在反馈那里问了下***“还有活着的开发人员吗”，第二天收到邮件“开发人员都在呢”，于是安心了。看小范围推行效果还行，最后才扩展到全公司的。&CTO俱乐部是目前国内最有影响力、规模最大的技术管理者分享与交流平台，由全球最大中文IT社区CSDN创办。CTO俱乐部实行会员免费申请、实名认证的加入机制。自2009年创办以来，已有注册会员10000余名，覆盖国内数千家IT公司和各行业企业研发部门的CTO、技术副总裁、首席架构师、技术总监、工程总监等高级技术管理者。
推荐阅读相关主题：
CSDN官方微信
扫描二维码,向CSDN吐槽
微信号：CSDNnews
相关热门文章