经验分享｜大型分布式团队的代码版本管理

经验分享｜大型分布式团队的代码版本管理

无论团队最终采用哪种代码版本可视化工具，只要团队的开发流程和工作方法合适，代码管理方法顺畅就可以了。

详细介绍这个话题有两个原因:

从开始工作到现在，我经历过沒有代码版本管理方法、代码集中型管理方法，及其如今的分布式管理方法，我刻骨铭心感受到它在开发软件全过程中的必要性；我工作中碰到的许多顾客都存有针对代码版本管理方法的各种各样难题、疑惑和不一样的要求。

所以我希望把我在这个层面的经验分享给大量的人，希望帮助大量的团队处理代码版本 *** 控中的问题和疑惑。

一、代码版本智能管理系统的历史时间

代码智能管理系统可以分为三个时期:

第一代：当地式

这一代的关键特征表现出本地代码版本 *** 纵，如SCCS(1972)、PVCS(1985)等。

这一代已经完成了基本的代码版本管理方法，但缺陷是不能让更多的人对一个版本库进行修改。这也和当时手机软件业务规模不够有关，没有这个要求。

第二代：手机客户端-网络服务器式

这一代的关键特征是显示服务器代码的集中版本 *** 作，比如CVS(1986)、ClearCase(1992)、VisualSourceSafe(1994)、Perforce(1995)、Subversion(2000)等等。

这一代主要完成了中心服务器的代码版本管理方法，特点是更多的人可以进行同样的工作，对代码版本库进行修改，但是缺陷也是非常显著的:

在没法连接网络的状况下，没法查询日志及其递交和较为代码版本（慢速度互联网和远程控制外地工作中的程序猿的痛），及其当服务项目或是互联网出現难题的情况下许多工作人员便会没法工作中。不兼容localbranch，造成branch建立管理方法繁杂，而且一旦建立就难以改动（快速迭代开发设计中的程序猿的痛）因为只有一个中心端网络服务器，一旦产生毁灭性难题，那麼全部日志都是会遗失，因此必须常常做备份数据（备份数据必须很大的成本费）假如手机软件代码量过度巨大，一般会出現速率迟缓的状况，由于每一次的日志查看、不一样版本中间的代码较为和代码递交等实际 *** 作都必须和网络服务器通讯，导致服务端的负荷过大。第三代：分布式

这一代的关键特征是显示分布式代码版本 *** 作，如Git(2005)、Mercurial(2005)等。

这一代结合了第一代和第二代的优点，完成了分布式代码版本管理方法。

这一代的优点:分布式管理方式，不需要连接网络服务器，仍然可以查询日志，提交代码，建立分支；适用于地方分公司，可以快速方便的完成各种分公司管理方式；一种分布式分级管理方法及其负载分离管理方法。

对于缺陷有一定的学习曲线，比如对泛在方法、本地分支、分布式代码管理方法中代码的理解和应用。详细可以参考:这里。

二、大中型分布式团队

以前也有这样的分布式团队。他们在几个大城市都有专业团队，开发设计了一个工程项目，如下图所示:

他们应用的代码版本可视化工具是第二代代码可视化工具SVN，管理系统如下:

然而，他们在整个申请过程中遇到了以下问题和麻烦。

因为它是一个分布式团队，因此:

根据团队的代码控制模块分离出来艰难

当网络服务器不可用时:

不可以查询递交纪录不可以较为文档不可以递交代码

建立代码分支时:

支系建立速度比较慢多支系管理方法艰难

提交代码时:

期待有CodeReview期待有CIReview

由于代码庞大:

查询日志慢

备份数据代码库时:

必须关机备份数据备份数据成本增加

对于以上问题，可以应用新一代分布式代码版本智能管理系统来处理，如下图所示:

其中每个团队都有自己独立的代码库，一个中央库用于共享这个独立的代码库，每个库都由团队自己管理和维护。并且代码版本智能管理系统必须适合轻量级分支、代码审查、离线提交、离线查询日志等功能。

然而，现在还没有一个单一的代码版本可视化工具可以考虑上述所有需求，因此许多企业根据它们开发和设计了集成的智能管理系统，如Gerrit、GitLab、GitHub、BitBucket等。其中，Gerrit因其开源系统，完全免费，由Google开发、设计和维护，管理方法具有Android、OpenStack等工程项目源代码的特点，成为大中型分布式团队的首选。

三、Gerrit

Gerrit是谷歌开发设计的系统软件，用于管理谷歌Android新项目的源代码。它是根据Java和Prolog开发设计的，是一个适用于Git、管理权限和代码评审的综合性智能管理系统。它与GitLab和GitHub的区别很大，它隐藏了代码库管理方法的关键点，提示开发人员开发、设计和提交代码，无需像fork那样的手动库和同步控制，节省了开发人员的时间，如下图所示:

由于Android本身是一个开源项目，推广人员众多，开发设计团队遍布几个区域(有时间差)，这就使得“如何保证代码质量”成为一个非常大的问题。所以Google给Gerrit增加了一个功能齐全且非常严格的代码审查系统软件。

起初，当代码被提交时，它不会被立即合并到中央存储库中。它将被临时存储在临时存储库中，并形成代码评审记录，请求评审的邮件将被推送给专门的评审人员。当审查者审查代码时，如果它是基于它的，则必须在Gerrit系统软件中对代码进行评分。如果是基于它，代码可以合并到中央库中。如果不是基于它，提交的代码必须返回给开发者修改。

另外可以全自动启动包括本次代码提交在内的CI建设(前提条件必须是手工制作，提前配备)。如果CI是全自动搭建和测试的，也可以在Gerrit系统软件中进行全自动评分，可以作为最终进行合并的工作人员的参考。有关提示，请参见下图:

由于Android源代码由一百多个独立的代码库组成，而一个Android系统软件的编译需要代码库中的大部分代码，如何管理这么多的代码库也是一个难点，比如如何用必须适合特殊机器设备的代码库一次性编译一个程序。因此，Google根据Python语言开发设计了一个叫做Repo的特殊工具。这个专用工具可以自定义你需要的代码库的组成，并且对这个代码库一次性进行相同的实现，比如拉、推，如下图所示:

四、SVN到Git的转移

对于想要从集中式代码智能管理系统转移到分布式代码智能管理系统的团队来说，如果团队管理规模较小，那么问题一般不大，但是对于大中型分布式团队来说确实比较困难。两个关键困难:

代码量很大，难以一次性将全部的代码和日志等在短期内内转移取得成功。因为属下团队过多，难以同一时间让全部团队都转换至新的代码可视化工具。

为了更好地处理这个困难，团队通常会首先应用新的代码版本可视化工具。如果这次团队转型成功，将以此为榜样向其他团队推广营销，然后所有团队逐步转换为新的特殊工具。

一般来说，SVN-Git转移计划的关键是应用两种特殊工具:

开源系统完全免费的git-svn；商业服务收费标准的Subgit。

应用子单位的调拨计划方案，如下图所示:

如果团队有足够的资源，也可以用Gerrit搭建一个单独的Gitweb服务器，然后以分布式的方式进行代码转移，如下图所示:

五、多产品系列的管理方法

将同一个中心代码库管理方法应用于多产品系列一直是工程项目中的难点，尤其是像SVN这样的专用工具的应用，更是无法管理。因为像SVN这种特殊工具的分支本质上是文件目录复制，速度比较慢，代码迁移必须手动进行。但如果将Git的特性应用于多产品系列的管理，与SVN相比将事半功倍。实际方案见下图:

汇总

分布式代码版本智能管理系统不一定适合所有团队。比如中小型团队很可能更注重的只是更低的成本，简单实用，所以SVN等集中式版本可视化工具还是比较合适的。但无论团队最终采用哪种代码版本可视化工具，只需要团队的开发流程和工作方法合适，代码管理方法顺畅即可。

创作者:刘冉，新ThoughtWorks杰出手机软件质量顾问，拥有超过13年的软件开发和测试经验。最熟悉的行业是嵌入式 *** 作系统开发与设计、Linux系统软件开发、各种脚本、测试工具、功能测试系统软件开发、敏捷中的QA。

文章内容创作者为@ThoughtWorks(微信公众平台:“管家行者”)，未经批准严禁拦截。

注:阅读相关网站基本建设方法的文章，请移至网站建设教程频道栏目。

欢迎分享，转载请注明来源：内存溢出

原文地址: http://outofmemory.cn/zz/769104.html