技术干货 | 阿里巴巴自研代码管理平台技术解密

【以下为分享实录，有删节】

阿里巴巴为什么要自研代码管理平台

也许你会问：为什么阿里巴巴要重新做一套代码管理平台，继续用GitLab版本不是挺好的吗？接下来从我个人的角度在这里尝试进行解答。

由于历史原因，在阿里巴巴集团内部代码平台是整个DevOps领域中起步相对较晚的一块业务域，相比于发布域、测试域有着多年的积累和沉淀来讲，2017年时的代码平台可以说是为了满足整体业务需求由几个系统强行拼凑起来的。

为了支撑起阿里巴巴整体的业务发展，研发团队要同时维护6个系统，分别是负责代码托管的GitLab、Svn、Gerrit，以及负责上层代码服务的Phabricator、CodeCenter、ScmCenter。且其中除了CodeCenter、ScmCenter之外，其它四个均是在开源系统之上二次封装改造而来的。其中Gitlab技术栈是基于Ruby，Phabricator基于PHP，SVN基于C，Gerrit基于Java,这给我们日常的开发和维护工作增加了很多负担。

当时代码平台遇到的困难和挑战主要有四个方面：

一、技术架构方面：多套系统架构，多种开发语言，不仅维护成本高，且与阿里集团的主流技术脱节，研发团队同学每天疲于填坑，然而整体上却得不到大的改善。

二、平台发展方面：单纯的Gitlab、Svn、Gerrit均无法与周边关联系统做到有效协同，且用户的多样性需求也很难在某个单一系统中得到满足，最关键的一点是我们虽然手握海量代码资产，但其宝贵价值却未有效挖掘出来。

三、外部市场方面：代码托管领域的市场是很有发展潜力的，但国内还没有一款真正To B形态的代码管理平台。这是因为对于科技企业来讲，代码是最核心的资产，企业把代码托管到谁的平台就等于把身家性命托付给了谁。因此一款To B形态的代码管理平台必须具备丰富的企业级特性以及完备的安全能力，然而在这一方面国内代码托管产品还有很长的路要走。

同时这也是“自主可控”的需要。作为托管代码的基础平台进行国产化既是大势所趋也是时代所需。只有将核心技术和产品把控在我们中国人自己手里才能从容面对未来各种不确定性。

四、代码文化方面：即如何正向推动阿里巴巴的代码文化传承。

阿里巴巴代码管理平台的整体策略

针对于以上代码平台所面临的四个方面的问题和挑战，该如何去解决，我们的整体思考和策略如下：

第一、统一架构，夯实基础：必须要统一架构，不能再在开源系统上拼拼凑凑，需要有一套完全能自主掌控的自研系统，从头夯实好基础。

第二、全面融合，高效协同：需要解决6套老系统如何与该自研系统过渡，同时该系统应该与DevOps领域中其它上下游系统能够方便的打通、协同。

第三，代码文化，品牌建设：在代码平台建设的同时，要考虑如何对阿里巴巴的代码文化和理念进行正向引导，从而做到以 工具 和平台作为载体，使代码文化进行有效落地。同时还要进行我们自己产品的品牌建设。

第四，拥抱智能，弯道超车：面对竞品我们如何才能真正脱颖而出、打出差异性，答案就是拥抱智能，通过智能化的手段进行弯道超车。

基于以上策略，我们开始了自研之路，全新的代码管理平台先是在阿里巴巴集团内部进行落地，进而解决了前文中提到的四个方面的问题。

经过充足的准备，我们将这款自研代码管理平台集成到云效中，成为了“云效代码管理平台”，即Codeup，目前开发者可从云效官网访问并免费使用。“云效代码管理”（Codeup）是一款企业级代码管理平台，提供代码托管、代码评审、代码扫描、质量检测等功能，保护企业代码资产，实现安全、稳定、高效的研发生产。抛开产品设计或团队打造这些方面，我们在技术上究竟是如何做的，这个我会在后面进行详细介绍。

云效代码管理平台的核心能力

云效代码管理（Codeup）主要提供代码浏览、代码评审、配置管理（SCM）、代码扫描、代码安全、CI/CD、文档、代码库迁移等能力和服务。

很多企业的技术负责人也许会纠结一个问题：将代码托管到云上是否安全？

一些企业在最终进行代码托管时，均会选择自己搭建代码托管系统，其实阿里早期也是如此，因此我们深知其中利弊。自己搭建代码托管系统，就需要做以下相关工作：首先，需要选择适合企业代码托管场景的开源软件；其次，准备托管的硬件设施。在此过程中，必须满足一些特定的要求，如需要对开源软件比较熟悉的技术人员进行搭建与维护；需要花费成本去购买实体或云端服务器；同时需要投入人力来负责安全及稳定性，否则就可能因为系统的稳定性而影响研发效率。

如果采用成熟的云端代码托管平台，就可以很好的避免上述问题。以云效代码管理平台（Codeup）为例，在代码存储方面，我们采用多副本高可用架构，数据自动备份；在代码安全方面，我们提供完善的安全权限机制和保护措施，降低内部成员泄露代码数据和外部黑客攻击的风险。

综合来看，对于中小企业及大型企业的开发人员，选择成熟的云端代码托管平台，是更安全更省心更经济的选择。

云效代码管理平台的系统架构

早些年，阿里巴巴集团内部采用的是AliGitLab系统架构，虽然在Gitlab上进行了分布式的改造，使这套系统的承载能力得到很大的提升。但是AliGitLab在架构上仍然属于单层分片架构，因为Web服务和Git托管这两个核心组件其实是部署在同一台机器上的，耦合十分严重，扩展能力非常差，且整个服务模块都是基于 Ruby 技术栈。这就使整个架构存在两个弊端：一是整个体系基于Ruby，导致维护、扩展以及人员培养成本都很大；二是Web服务和Git托管耦合在一起，很多情况下会因为某个节点上代码库读写占用大量资源而对用户在该节点上的页面访问或API服务请求造成影响。

针对上述问题，我们在云效代码管理平台（Codeup）上实现了全新的架构。通过明确的抽象、分层，将Codeup整体划分为三层，即由下至上为存储层、代理层和服务层。同时抽取出5个系统核心组件，服务组件间彼此职责单一、分离，上层Service和Portal基于 Java 进行实现，无状态；存储层及代理层组件全部用 Go 语言编写。Codeup-stone主要负责文件存储及底层Git操作的封装，其上抽取一个中间代理层，各层之间基于GRPC协议进行高效的数据传输。服务层的各项请求都基于Codeup-Proxy去与存储层打交道，从整体上大幅增强了系统的容灾能力和扩展性，每一层都可以做到方便的扩容、缩容。这套自研系统架构经过多年打磨和演进，在阿里巴巴集团内部承载起了数万工程师，上百系统的大规模、高并发的日常调用压力。

在开发者最关心的稳定性和文件存储方面，我们采用了多节点“分片”和单节点“一主多备”以及跨机房“冷备”的手段，来保障数据的高安全和高可靠性。同时云效代码管理平台（Codeup）全部组件均架构在阿里云基础设施之上，以此来确保存储、应用服务器、网络等硬件方面的安全稳定。

在数据存储和高可用方面，我们具体采取了以下三点措施：一、在底层存储节点上，对代码库进行哈希散列处理，从而避免存储节点因为仓库分布不均匀而成为“热点”；二、针对单个节点可能因为存储“大库”而成为“热点”的问题，Codeup通过多副本的方式对单个节点的请求进行负载均衡，根据实际流量，可以进行快速的扩容或缩容；三、在仓库数据备份方面，我们采取了多份热备份和一份冷备份的方案。其中，热备份至少会存在两份，冷备份存储全量的数据快照。针对用户由于误操作产生的数据删除等不可逆的问题时，我们可以通过冷备份的数据快照进行恢复。目前快照数据保存的周期为一周。

除了基础架构，我们在代码智能化、代码规范化等方面也做了大量的投入。基于阿里巴巴集团内部海量的代码数据，在代码安全、代码质量和研发提效等方面的我们都进行了大量探索和创新。这次也是希望借助我们自研的云效代码管理平台（Codeup）将这些优秀的能力开放出去，普惠更多中小企业。接下来，我会针对Codeup上代表性的功能和工具进行详细介绍。

人工智能技术助力敏感信息监测

首先，我们来了解一下云效代码管理平台（Codeup）在企业智能安全方面的功能。我们为企业管理者提供了安全风控、审计日志、IP白名单等把控代码库安全的核心能力。今天主要介绍一下敏感行为监测，我们是如何做的。

首先，我们以代码数仓为基础构建了代码图谱，通过对代码库、代码、工程师进行抽象将其转化为实体，并通过实体的标签化构建代码画像、用户画像等。为智能服务提供有力的数据支持，为平台业务提供推理关系查询。在敏感行为检测这个例子中，我们提取出了代码库重要度、文件重要度、代码段重要度、开发人员近期浏览行为、开发人员画像作为安全防护的支撑内容。一旦有重要库、重要文件发生敏感操作，如突然的大量代码库下载、删库、权限变更等行为，我们会立刻给订阅用户发送通知告警，帮助企业管理者感知风险，及时止损。

代码质量—饱受好评的P3C代码规约检测插件

在代码质量方面，云效代码管理平台（Codeup）内置了我们自研的P3C代码规划检测插件。这款插件在阿里巴巴内部饱受好评，使用广泛；目前已经开源，在业界也很受欢迎，无论是插件的下载量，还是在Github源码工程上的加星数都很高。那么，P3C技术上是如何实现的呢?

经过多次调研和探讨，我们选择了开源代码扫描工具PMD去做资源与规则扩展，主要是看中了其规则扩展方便，集成到其它通用平台和插件上更灵活的特性。但PMD也有其局限性，即不支持跨文件扫描（例如：对过时方法的检测），所以那些需要针对跨文件扫描的规则我们提到了Sonar、IDE等上层工具去实现。

• 方案选定后，我们基于开源的pmd-core三方Jar的能力上，扩展了约60个规约扫描规则，并封装出P3C-PMD组件。

• 在P3C-PMD组件基础上，基于Sonar插件扩展标准，我们提供了sonar-p3c-pmd-plugin，也就是封装出了一个标准的Sonar插件。此插件主要用于代码库全量自动化扫描阶段。

• CodeReview插件采用直接类似于命令行调用的方式集成了p3c-pmd，主要针对于增量代码检测阶段。

• 在P3C-PMD组件基础上，基于IDEA的Inspection机制，以及Running Inspection By Name的功能自主实现了IDEA插件。

• Eclipse插件主要是基于原生已有的Eclipse PMD插件进行的规则替换开发。我们通过IDE插件的实现，进而解决了本地代码规约检测的问题。

综上所述，我们通过不同的插件覆盖了不同研发阶段（如本地编码阶段，自动化全量测试阶段、CodeReview增量检测阶段）的代码规约检测。通过本地结合线上、全量结合增量的策略，我们实现了一套规则落地多端，进而将阿里巴巴Java编码规约通过工具化平台化的手段在阿里内部进行了充分落地。2017年10月份，我们在GitHub上将P3C规则和工具的源码正式对外开源。

通过以上努力，我们不仅将P3C工具在阿里巴巴集团内部进行了有效落地，同时在集团外也树立了很强的品牌影响力。规约检测工具保证了规约文化的落地及传播，同时规约文化又从效能、人才、稳定性等方面正向推动了整个研发体系的完善。

代码质量—缺陷检测技术PRECFIX技术揭秘

由于阿里巴巴集团业务发展的复杂性，上文提到的P3C、PMD等传统自动化检测工具不能完全解决阿里巴巴面临的代码质量问题。因为传统工具多是基于规则匹配，不需要了解特定的场景，基于业务场景的BUG很难通过这些自动化工具识别出来。例如有众多的缺陷类型难以定义，这样就没办法提取出有效的匹配规则。因此我们希望有一种对缺陷类型泛化能力比较强的缺陷检测方法或者工具，于是提出了PRECFIX方法（Patch Recommendation by Empirically Clustering）。

PRECFIX的技术思路其实并不复杂，主要分为三步，首先从代码提交数据中提取“缺陷修复对”，然后将相似的“缺陷修复对”聚类，最后对聚类结果进行模板提取，这个缺陷检测和补丁推荐技术可以用于代码评审，全库离线扫描等等。用户的反馈以及我们人工的审查可以进一步提高模型推荐质量。

与国外友商的产品对比，PRECFIXP具有毫秒级检测，覆盖较多的场景，能修复部分偏业务缺陷等特性。

PRECFIX方法已经在阿里巴巴集团内部落地，在内部公开库中扫描出了800多种缺陷类型，3万多个缺陷，提取出了3000多个模板。此功能将在这个月底前（2020年4月）通过云效代码管理平台（Codeup）开放给用户使用。

代码安全-敏感信息检测SecretRadar

我们知道每天都有成千上万条诸如API Key、 Database credential、Private token等敏感信息通过某些站点被无意识的泄露出去。为了预防这类问题，我们决定在云效代码管理平台（Codeup）提供敏感信息检测的能力。

因此调研了业内多款敏感信息检测产品，包括比较知名的Truffle Hog、Watchtower等。但是这些工具要么单纯考虑规则匹配，要么采用信息熵技术，召回率或准确率无法满足我们的预期，模型最终效果都不是非常理想。因此，我们在规则匹配和信息熵技术的基础上，结合了多层检测模型和上下文语义检测，打造了一款敏感信息检测工具 ——SecretRadar，从而使识别效果得到了显著提升。

SecretRadar的实现思路主要分为三个层面，第一层我们采用传统敏感信息识别技术通过丰富的规则集来保证模型基础能力的稳定和可靠，同时确保了模型良好的可扩展性，以此来支持后续用户自定义的能力。但是这种方法非常依赖固化的长度、前缀、变量名等，匹配效果上容易造成漏报。因此针对难以固定规则捕捉的场景，在第二层我们采用了信息熵算法。信息熵可以用来衡量数据集的信息量大小，也就是其不确定程度。所以数据集的信息熵越大，无序程度就越高。通过计算信息熵，可以有效识别随机生成的密文信息，从而提升模型的召回能力，补足基于规则手段的漏报问题。同样信息熵算法也有其局限性，伴随召回的提升是误报率的增加。因此在第三层我们采用了模板聚类的方法，进行了过滤优化。针对信息熵结果集聚合提取常见关键字，并结合上下文分析，来完成二次过滤。同时通过问题的修复情况，建立二分类数据集，完成算法优化。进而从词法识别迭代为语义识别。

智能评审助力开发者提升研发效能

在研发提效方面，我们认为代码评审是一个很好的抓手。在调研、学习了国际上多款优秀产品的基础上，结合阿里巴巴复杂、多样的研发场景，我们历时两年打磨出来一套非常好用的代码评审模块。结合人工智能技术，我们在业内首创了评审耗时预估、评审人自动推荐等功能。

接下来我们详细了解一下评审耗时预估。“评审耗时预估”有什么意义呢？我们都知道，代码评审的工作量“可大可小”，主要取决于评审代码改动量的大小和业务逻辑的复杂度。作为软件开发工程师，大家平时的工作都很忙，只能在开会或编码的间隙中抽出特定时间来做代码评审。但往往代码评审的工作量超出了评审者的预期。同时也存在一些极端情况，某些小的评审可能只需要几十秒就可以评审完毕，但是评审者在不知情的情况下却为它安排了大段的评审时间。

“评审耗时预估”主要服务于两种场景，第一个场景是用户在未进行评审之前，可以在第一时间知晓评审的工作量，辅助他合理安排评审时间；第二个场景是对于那些同时要进行多个代码评审的用户，可以帮助他们合理安排评审的优先级。

“评审耗时预估”到底是如何实现的呢？首先我们基于阿里巴巴集团内部海量的公开代码数据，收集了几百万次的评审文件浏览数据，提取了包括文本改动、项目历史、行为历史在内的数十种特种，训练了机器学习模型。当开发者提交代码评审之时，我们根据他提交代码的Diff内容，自动估算出评审耗时，并伴随代码评审通知一起来告知评审者，帮助他合理安排评审时间。以上能力会在用户授权的情况下，陆续在云效代码管理平台上开放给大家使用。

 动动小手指 了解更多详情 ！