【转】当版本管理遇到敏捷
当版本管理遇到敏捷
版权声明：转载时请以超链接形式标明文章原始出处和作者信息及本声明
http://dreamhead.blogbus.com/logs/36730487.html
很早就知道Cruise团队在使用Mercurial（Hg），直到现在这个项目上，我才有机会第一次近距离接触分布式版本管理工具。
客户的版本管理工具是ClearCase。我们所到的项目组，版本管理工具就变成了Hg。
为什么是Hg？因为这是先行几个同事的选择，所以，一开始，我并没有仔细考虑过这个问题，我只是下意识的不喜欢ClearCase这种重量级的版本管理工具。随着工作的深入，包括最近开始做一些跨项目组的工作时，我逐渐开始意识到，正是因为当初选择了Hg，我们的工作才得以顺利开展。
就从ClearCase说起吧！
如果你用过ClearCase（SourceSafe也一样），你就会知道，要想修改一个文件，你必须先把这个文件Checkout，修改，然后再Checkin。在你Checkout这段时间，别人是不能对这个文件做任何修改的。ClearCase这种工作方式称为悲观锁，道理上来说，它最大程度上限制了文件冲突。但实际上，这种做法极大限度阻碍人们向库中提交代码。
一个人修改时，其他人是不能修改的，这会把我们本应并行的工作改成串行。当然，我们都是有职业道德的，所以，我们可能选择的一种工作方式是把这些文件复制到另外一个目录，在那个目录里面工作，然后，要提交了，再把代码复制回来。无论如何，这是一种费力的做法。一旦一件事做起来比较麻烦，人们就会倾向于不做，或少做。所以，其结果就是本地堆积了一大堆代码，很长一段时间才提交一次。显然，这与敏捷中提倡的频繁提交是相背离的。
别以为我为赋新词强说愁，这是我亲眼所见。换上Hg的项目组，提交的频率明显大幅度提高了。基于悲观锁的版本管理工具在敏捷面前成了绊脚石。
在使用Hg之前，我最熟悉的版本管理工具是SVN，在我经历的项目中，一直也用的很好。甚至我加入这个项目很长时间之后，我一直为这个项目选用Hg而非SVN耿耿于怀。分布式版本管理最让我喜欢的一点是，可以在没有网络的情况下，进行提交，满足我——一个ThoughtWorker频繁提交的心理需求，要知道，我经常会偷偷自己编一些代码。而这个项目，这一点是完全没有必要的，因为大家的开发肯定都是在一个局域网内。加之，分布式版本管理既要提交到本地版本库，又要推送到服务器上，比起集中式管理要多敲一条命令。你知道，我一直以自己是个懒程序员为荣的。
但是，我们最近进入到跨项目组的工作，分布式管理工具的价值就体现无遗了。因为整个的开发团队有太大的规模，让大家工作在一个服务器上，冲突的概率太大。所以，我们给出了一个分级的方案，也就是说每个项目组有自己的服务器，一段时间把每个项目组的工作同步到整个团队的服务器上。使用分布式版本管理，在不同的服务器上同步代码相对容易很多。有兴趣的话，你可以想想，如果采用集中式的版本管理，这个问题该如何解决。
原本我想写一篇关于Hg的文章，但胡凯的文章让我觉得没有这个必要了。唯一需要补充的一点是，Hg本身有很强的扩展功能，我在这个项目上就写了一个扩展，使得CC中的符号链接在Hg中得以保持，所以，如果对Hg有更高的要求，自己动手写一个扩展就好了。
当版本管理遇到敏捷（二）
版权声明：转载时请以超链接形式标明文章原始出处和作者信息及本声明
http://dreamhead.blogbus.com/logs/45327898.html
如果我是一个咨询师，我就要面对一个叫做ClearCase的版本管理工具，
我是一个咨询师吗？是的。
所以，我还得面对ClearCase。
虽然，我曾经在不少人面前举证过ClearCase的种种不是，但当我出现在一个新团队的面前，我还要想办法，让他们相信我说的是真的。
几个月前，我的说辞是ClearCase在乐观锁问题上表现不佳。这次，我遇到了一个告诉我ClearCase支持乐观锁的人。其实，我也知道ClearCase支持乐观锁，但我就是不喜欢这种把人教坏的重量级工具。我以乐观锁的方式试用了ClearCase，结果是更加坚定了我的信念。
ClearCase在修改一个文件之前，必须先将文件CheckOut出来，乐观锁的方式只是说，多个人可以同时CheckOut一个文件，但无论如何CheckOut的动作是不可或缺的。作为一个开发人员，我编写代码之前，是无法完全预期我要改哪些代码的，所以，我不可能在每次修改之前，把所有用到的代码都CheckOut出来的。如果在写代码的过程中，遇到了一个要修改的文件，就要做一次CheckOut，想一下，我都会觉得麻烦。工具是用来为人服务的，而不是添乱的。
Subversion相较于CVS的一个重大进步是对重构的支持，比如文件改名，历史仍得以保存。ClearCase在这方面做得也很好，也能在文件改名的情况下保留历史。但是，它的修改操作是直接在服务器上完成的。在敏捷的团队里面，CI纪律要求所有人必须在本地修改验证完成才能提交代码。直接修改服务上的内容，对CI来说，是非常不安全的，因为很有可能会造成提交的不完整。不完整的提交结果就是，持续集成会失败，而这种失败实际上是一种假失败。经常性的假失败，就会造成团队不再信任CI，CI也就成了无人关心的破窗户。
与不完整提交相关的另外一点是原子提交。如果不支持原子提交，就有可能出现提交过程中，出现失败，只有一部份文件提交成功，造成不完整提交。不完整提交的后果，前面已经说了。ClearCase恰好不支持原子提交。
关于ClearCase，有一点我不得不说，虽然与敏捷可能并不直接关系：符号链接。ClearCase中的符号链接同操作系统的符号链接是异曲同工的。正是因为ClearCase支持，我所接触的团队居然可以把符号链接用到难以想像的地步，漫天遍野的符号链接，却从来没有仔细考虑过重新组织一下文件结构，让代码做到真正意义上的只有一份。或许，这不应该算是工具的错。SVN也支持符号链接，但至少我在使用SVN从来没有使用过。工具也是俱备很强引导性的，这也就是为什么我说工具会把人教坏。在前一个项目里面，因为开发团队已经在开发之中，我们不得已用Hg的钩子这种旁门左道解决问题。再次面对它，我们有机会用正道——调整文件组织，彻底的解决这个问题。
说起来，其实只是一些地方的细微差别，但就是这些细微的差别，就会让人用起来很不舒服。失之毫厘，谬以千里。
当版本管理遇到敏捷（三）
版权声明：转载时请以超链接形式标明文章原始出处和作者信息及本声明
http://dreamhead.blogbus.com/logs/62181322.html
我终于遇到了一个不用ClearCase的团队。在我到来之前，他们就从ClearCase切换到SVN。我欣喜若狂，准备卷起袖子大干一场。
一天，我找到一个开发人员了解构建脚本的情况。
我：构建脚本都写好了吗？
开发人员：写好了。
我：都上库了吧？
开发人员：没有。
我：为什么？
开发人员：我要删掉一些旧的东西，但是我没有删除权限。
我：……
这番对话让我意识到有不对劲的地方。我开始了新一轮的调研，结果出乎我的意料。这个团队虽然切换到了SVN，但是，他们并没有像我想的那样在使用SVN。
同团队负责版本管理的人进行交流，之所以要限制删除权限，是怕成员误操作。好像版本管理工具是有历史的吧！不仅是没有删除代码的权限，更有甚者，他们是用锁来保证团队成员不会产生提交冲突。于是，这个团队的成员开发时，会把代码复制到另外一个地方，写完代码之后，通过工具对比，再合并回来，然后，获取锁，提交代码。这恰恰就是我在《当版本管理遇到敏捷》里描述的某些团队使用ClearCase的操作方式。
ClearCase人走了，神还在。
之所以采用这种做法，因为在他们看来，把代码提交到版本管理工具中是一件非常严肃的事，不能有丝毫的偏差。因为按照他们之前的做法，一旦出错是要很长时间才能暴露出来的。于是，他们采用了这种“防止犯错”的方法。
《第五项修炼》提到的修炼法则有一条是，今天的问题来自昨天的解决方法。有一种实践叫做“持续集成”，它的目的就是为了快速反馈，尽早发现问题。这种可能引发编译错误的误操作应该第一时间就可以发现。
还有一个团队，依然在使用ClearCase，他们一年前曾经对比过ClearCase和SVN，得出的结论是ClearCase更好。我看到了这份对比报告，他们的人问我如何评价。我说，把SVN当作ClearCase用，当然没有ClearCase好用了。
显然，他们要走的路更长。
