Dec December 2011

企业版本控制的改革:从ClearCase到Git--我的布道之旅

企业版本控制的改革:从ClearCase到Git--我的布道之旅

前沿

特别声明:本文专为图灵社区活动“唤醒你心中的布道师”而写,欢迎大家积极参与!

特别感想:本文的风格照搬高翌翔的“布道体” 从自定义ORM框架到NHibernate——我的识道、行道、布道之旅

程序员杂志第十二期中讲到了企业开发的困境,其中有一点就是企业的流程和工具很难适应新的敏捷开发模式。我认为其中之一就是版本控制系统,本文就是探讨一下我是如何来推动这个改变的,也就是我的布道之旅。

【免责声明】这里不是探讨两种技术的好坏,而是如何推动变革,每个技术都有适应的场所,请勿生搬硬套。关于版本控制的选择,可以看看Martin Fowler写的版本控制工具(english)

介绍

在传统企业中,版本控制系统大都采用ClearCase,因为在早期它应该提供了强大的企业应用的功能,我们企业也很早使用了。而且长久以来,在它周围建立了无数的应用和流程,同事们都觉得它是必须的了。

然而随着敏捷和开放的推动下,在有些产品用Clearcase开发碰到了很多局限,比如在家上班,远程团队开发。有人开始想到引入其他工具(svn,git)来解决,不过在大型企业中要改变这种基础的工具是很难的。

我做为一个软件开发的探索者,努力的想改变点什么,但不知从何而起。

了解分布式版本控制(DVCS)——初识道

开始考虑这个的时候是在2009年初,svn是第一个考虑的对象,因为它在开源中用的最多,sourceforge和eclipse的很多项目多用它,但我总觉得缺了点什么。

恰好我有个Geek朋友:陈忠克极力推荐一个分布式版本控制工具:mercurial,说实话听了介绍不是很懂,没有眼前一亮的感觉。聊了一下,感觉和svn的分支没有多大区别,还两层提交呢。

同时他也告诉我还有其他的分布式版本控制工具git,bazaar可供选择。

不管怎么样,我了解了这块领域有了最新的技术,或许能解决我们的问题。

尝试在日常中使用分布式版本控制——初行道

为了尽快了解DVCS,我决定要在日常的开发中用用它,实践它,尽快的掌握它的关键。

由于Geek对mercurial很熟,我就踏踏实实的用mercurial用了两个星期,不懂就问他,顺便查查资料去比较一番。

wooh,wooh,DVCS真是很神奇,很好用,特别对我(作为码农)的胃口,感觉DVCS天生是为软件开发用的。

在同一时刻,我又比较深入的看了看其他的系统如git,发现git的生态圈更好一点。在软件开发中,生态圈会决定将来这个工具的发展趋势。

  • 如eclipse插件开发邮件中开始讨论并决定用git替代svn。
  • git有很多的书可供选择(如 ProGit),git在线网站的内容也极其丰富。
  • github也漂亮得提供git的支持。补充一下,那时候bitbucket和github还在同一个水平线上。google code也还不支持git,只有mercurial和svn。

通过这些实践和了解,发现DVCS:git很适合我们所在的企业产品软件开发。

宣扬和推广分布式版本控制——初布道

要在企业中换一个版本控制工具难度非常大,所以必须要造势,也就是此处的布道,我采用了下面的方法:

  1. . 每月我们都有固定学习新东西的时间,我就推荐了mercurial、git两个课程,让大家共同来学习,了解它。顺便我要看看开发者对它的接受程度,有趣的是,水平越牛的人越是喜欢它,纷纷过来问什么时候能在产品开发中用上git。
  2. . 除了开发者,管理者和其他的使用者(配置管理的同事)的想法也很重要。我经常抓住机会和这些人聊DVCS ,聊git,给他们介绍,看看他们有什么想法。当然他们会不同意我的观点(有强势的,有委婉的),我就试图去说服他们,挖掘出推动这个变化的关键因素。

慢慢的我就开始得到了很多如何推动这个变化的材料,以及说服他们的模板(哈哈对症下药)。

详细研究版本迁移——再识道

开发者想使用分布式版本控制的呼声越来越高,管理者也开始认真考虑了。

在企业中,改变所需要的研究评测报告(word,ppt)是必不可少的了,这也给了我一次重新认识集中式和分布式版本控制的过程,我花了更多的时间去想这个改变对企业带来的好处。实际上开发者有时候不会考虑到整个软件开发的所有方面,如安全,持续集成等等。报告的大致框架是:

  • 现在问题是什么?
  • 什么是DVCS,git是什么?
  • 能改变什么?带来的好处?
  • 如果变化,计划是什么?

研究报告就不细讲了,太技术了,而且有点商业机密,哈哈。

这一期间,使我更详细的了解了git和对企业可能的影响(有好的,有坏的),并制定了相应的对策。

开始在小范围实施——再行道

布道需要耐心和机遇,机缘巧合,迁移到git的建议比较顺利的被管理层接受了。(我的报告难得那么顺利通过的)。

然后就是要去认认真真的实施了,这不是一个小问题,既然是软件开发,来不得半点的马虎,细节决定一切。而且实施的好坏还涉及到自己的面子问题,讲笑了。

企业中一般从小范围开始实施,成功了才推广,下面是我们的一些实践。

  • 我们用gitolite作为git服务器,架好试验平台,在一个小项目中开始尝试。
  • 人手一本git的书,安排git入门培训,提高驾驭git的能力。
  • 不断收集资料,提高对git的认识。

还好基本上没有出大的差错,虽然有蛮多技术难点的,不过最后都解决了。通过小范围的使用推广,我们的技术储备也加强了(特别是配置管理的人),对下一步的全面实施更有信心。

推广,并引入gerrit做代码审查——再布道

早期我们用的是gitolite来架git服务器,它很不错。不过后来发现gerrit更好用,后来就切换过去使用了。这一点很重要,要不断探索这些新技术,争取在大规模推广前,用一个最适合的工具,否者一用上,在企业中就很难改变了。

git开始在更多团队和更多产品中使用后,我们不断加强知识的培训,而且把相关的系统(如持续集成)都迁移到git上去。一切都还不错,只是git比想象中还复杂一点。

因为gerrit有很强大的代码审查(code review)功能,不久以后这个功能也用上去了,代码提交的质量一下子上了一个档次,这是开始推动git变革时没有想到的。

结束语

(此处引用高翌翔写的“布道体”结束语)

子曰:己所不欲,勿施于人。因此,布道者在布道前,须识道、行道,而布道时应谨记“己之所欲,慎施于人”,身教重于言教,务必身体力行、以身示道!

我的识道、行道、布道之旅没有终点,希望能结识更多的同路人 ;-)

其他

本文也是我用git记录在github上的,你可以看到每次的变化。

如果对此文有兴趣,帮忙顶一下,别忘了 @larrycaiyu ,希望有机会有人能帮我推荐到QConf 2012中去分享,到时我们可以探讨的更多。

顺便推荐蒋鑫《Git权威指南》,国内少有的好书。

blog comments powered by Disqus
comments powered by Disqus