阿里巴巴为什么要重新做一套代码管理平台，继续用版本不是挺好的吗？

阿里巴巴为什么要自研代码管理系统

虽然你会问：为什么阿里巴巴要再次做一套代码管理系统，继续用版本不是很好的吗？接下去从我个人的视角在此处尝试进行解答。

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

为了支撑起阿里巴巴整体的业务发展，研发队伍要同时维护6个平台，分别是负责代码托管的、Svn、，以及负责上层代码服务的、、。且其中不仅、之外，其它四个均是在开源平台之上二次封装改造而来的。其中科技栈是基于Ruby，基于PHP，SVN基于C，基于Java,这给我们日常的开发和维护工作提高了这些负担。

原本代码系统遭遇的困难和挑战主要有四个方面：

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

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

三、外部市场方面：代码托管领域的行业是很有发展潜力的，但中国还没有一款真正ToB形态的代码管理系统。这是由于针对技术企业来讲，代码是最核心的资产，企业把代码托管到谁的平台就等于把家产性命托付给了谁。因此一款ToB形态的代码管理系统需要具有丰富的企业级特征及其完备的安全素养，然而在这一方面中国代码托管产品也有很长的路要走。

同时这只是“自主可控”的还要。作为托管代码的基础系统进行国产化既是大势所趋也是时代所需。只有将核心科技和产品把控在我们日本人自己手里能够从容应对将来各种不确认性。

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

阿里巴巴代码管控系统的整体思路

对于于以上代码系统所遭遇的四个方面的难题和挑战，该怎么去解决，我们的整体构想和思路如下：

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

第二、全面整合，高效协同：需要缓解6套老平台如何与该自研平台过渡，同时该系统需要与领域中其他上下游平台无法便利的畅通、协同。

第三，代码文化，品牌建设：在代码系统建设的同时，要考量如何对阿里巴巴的代码文化和观念进行反向引导，从而做到以软件和系统成为契机，使代码文化进行有效落地。同时需要进行我们自己产品的品牌建设。

第四，拥抱智能，弯道转弯：面对竞品我们怎么能够真正脱颖而出、打出差异性，答案就是拥抱智能，通过智能化的方式进行弯道超车。

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

经过充足的打算，我们将这款自研代码管理系统集成到云效中，成为了“云效代码管理系统”，即，目前开发者可从云效官网访问并免费使用。“云效代码管理”（）是一款企业级代码管控系统，提供代码托管、代码评审、代码扫描、质量监测等用途，保护企业代码资产，实现安全、稳定、高效的研制制造。抛开产品设计或团队推出很多方面，我们在科技上到底是怎样做的，这个我会在上面进行具体介绍。

云效代码管控系统的核心能力

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

这些企业的科技负责人虽然会纠结一个难题：将代码托管到云上是否安全？

一些企业在最后进行代码托管时，均会选取自己建立代码托管平台，其实阿里初期只是那么，因此我们坚信其中缘由。自己建立代码托管平台，就必须做下面相关工作：首先，需要选用合适企业代码托管场景的开源工具；再者，准备托管的硬件设备。在此过程中，必须满足一些特定的规定，如必须对开源工具相当熟悉的科技人员进行构建与维护；必须耗费成本去购买实体或云端服务器；同时还要投入人力来负责安全及稳定性，否则就或许由于平台的稳定性而妨碍研发效率。

如果采用成熟的云端代码托管系统，就可以较好的防止上述弊端。以云效代码管理系统（）为例，在代码存储方面，我们引入多副本高可用架构，数据手动备份；在代码安全方面，我们提供建立的安全权限模式和保护机制，降低外部成员窃取代码数据和内部黑客攻击的风险。

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

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

早些年，阿里巴巴集团外部引入的是平台架构，虽然在上进行了分布式的改造，使这套平台的承载能力受到巨大的提高。但是在架构上一直属于单层分片架构，因为Web服务和Git托管这两个核心模块虽然是推进在同一台机器上的，耦合十分严重，扩展能力相当差，且整个服务组件都是基于Ruby技术栈。这就使整个架构存在两个问题：一是整个制度基于Ruby，导致维护、扩展并且人员培养成本都很高；二是Web服务和Git托管耦合在一起，很多状况下会由于某个节点上代码库读写占用大量资源而对客户在该节点上的页面访问或API服务请求导致影响。

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

在开发者最关心的稳定性和文件传输方面，我们引入了多节点“分片”和单节点“一主多备”以及跨机房“冷备”的方式，来保障数据的高安全和高可靠性。同时云效代码管控系统（）全部模块均架构在阿里云基础设备之上，以此来保证传输、应用服务器、网络等软件方面的安全稳定。

在数据存储和高可用方面，我们详细采取了下列三点机制：一、在底层存储节点上，对代码库进行哈希散列处理，从而导致储存节点由于仓库分布不均匀而作为“热点”；二、针对单个节点可能由于传输“大库”而作为“热点”的难题，通过多副本的方法对单个节点的请求进行负载均衡，根据实际流量，可以进行迅速的扩容或缩容；三、在仓库数据备份方面php云人才系统怎么看源码，我们采取了多份热备份和一份冷备份的方案。其中，热备份至少会存在两份，冷备份储存全量的数据快照。针对客户由于误操作造成的数据删除等不可逆的弊端时，我们可以借助冷备份的数据快照进行修复。目前快照数据保存的周期为一周。

比如基础构架，我们在代码智能化、代码规范化等方面也做了长期的投入。基于阿里巴巴集团外部海量的代码数据，在代码安全、代码品质和开发提效等方面的我们都进行了长期探索和变革。这次只是期望通过我们自研的云效代码管理系统（）将这种优秀的素质开放出来，普惠更多中小企业。接下去，我会对于上代表性的用途和工具进行具体介绍。

人工智能科技推动敏感信息监测

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

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

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

在代码质量方面，云效代码管控系统（）内置了我们自研的P3C代码规划评估软件。这款插件在阿里巴巴内部受到好评，使用广泛；现在早已开源，在业界也很受欢迎，无论是软件的下载量，还是在源码项目上的加星数都很好。那么，P3C技术上是怎样实现的呢?

经过多次考察和分析，我们选取了开源代码扫描软件PMD去做资源与规则扩展，主要是看中了其规则扩充方便，集成到其他通用系统和软件上更灵活的特点。但PMD也有其局限性，即不支持跨文件扫描（比如：对过时方法的测试），所以这些必须对于跨文件扫描的规则我们看到了Sonar、IDE等上层工具去实现。

综上所述，我们借助不同的组件覆盖了不同开发阶段（如本地编码阶段，自动化全量测试阶段、增量检测阶段）的代码规约检测。通过本地结合线上、全量结合增量的思路，我们推动了一套规则落地多端，进而将阿里巴巴Java编码规约通过软件化系统化的方式在阿里内部进行了充分落地。2017年10月底，我们在中将P3C规则和软件的源码正式对外开源。

通过以上努力，我们虽然将P3C工具在阿里巴巴集团外部进行了有效落地，同时在集团外也确立了很强的品牌影响力。规约检测软件保证了规约文化的落地及传播，同时规约文化又从效能、人才、稳定性等方面正向推动了整个开发模式的构建。

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

因为阿里巴巴集团业务发展的复杂性，上文提及的P3C、PMD等传统手动化测试软件不能完全解决阿里巴巴面临的代码品质问题。因为传统软件多是基于规则匹配，不应该知道特定的画面，基于业务场景的BUG很难通过这种手动化工具识别出来。例如有很多的弊端类型无法定义，这样就没办法提取出有效的匹配规则。因此我们期望有一种对缺陷类型泛化能力非常强的弊端检测方式以及软件，于是强调了原则（Patchby）。

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

与美国友商的产品对比，具有毫秒级测试，覆盖较好的场景，能恢复部份偏业务弊端等特点。

方式尚未在阿里巴巴集团外部落地，在内部公开库中扫描出了800多种缺陷类型，3万多个缺陷，提取出了3000多个模板。此功能将在这个月份前（2020年4月）借助云效代码管控系统（）开放给用户使用。

代码安全-敏感信息检测

我们知道每天都有成千上万条诸如APIKey、、token等敏感信息通过这些站点被无意识的泄露出来。为了防止这类问题，我们决定在云效代码管控系统（）提供敏感信息检测的能力。

此外调研了业内多款敏感信息监测产品php云人才系统怎么看源码，包括非常知名的Hog、等。但是这种工具要么单纯考虑规则匹配，要么采用信息熵技术，召回率或具体率难以满足我们的预期，模型最终效果都不是十分理想。因此，我们在规则匹配和信息熵技术的基础上，结合了多层检测模型和上下文语境检测，打造了一款敏感信息监测软件——，从而使识别效果受到了明显提高。

的推动模式主要分为三个层面，第一层我们引入传统敏感信息识别科技通过丰富的规则集来确保模型基础素质的稳固和牢靠，同时保证了模型良好的可扩展性，以此来支持后续用户自定义的能力。但是这些方式十分依赖固化的长度、前缀、变量名等，匹配效果上易于导致漏报。因此对于难以固定规则捕捉的画面，在第二层我们引入了信息熵算法。信息熵可以拿来衡量数据集的信息量大小，也就是其不确认程度。所以数据集的信息熵越大，无序程度就越高。通过推导信息熵，可以有效辨识随机生成的密文信息，从而提高模型的召回能力，补足基于规则形式的漏报问题。同样信息熵算法也是其局限性，伴随召回的提高是误报率的降低。因此在第三层我们引入了模版聚类的方式，进行了过滤优化。针对信息熵结果集聚合提取常见关键字，并结合上下文分析，来完成二次过滤。同时借助问题的恢复状况，建立二分类数据集，完成算法改进。进而从词法辨识迭代为词义辨别。

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

在研发提效方面，我们觉得代码评审是一个较好的契机。在调研、学习了国际上多款优秀产品的基础上，结合阿里巴巴复杂、多样的开发场景，我们历时三年打磨出来一套特别好用的代码评审模块。结合人工智能科技，我们在业内首创了评审耗时预估、评审人手动推荐等功能。

接出来我们具体认识一下评审耗时预估。“评审耗时预估”有哪些意义呢？我们都明白，代码评审的工作量“可大可小”，主要取决于评审代码改动量的大小和业务逻辑的复杂度。作为工具研发项目师，大家经常的工作都很忙，只能在上课或编码的空隙中抽出特定时间来做代码评审。但往往代码评审的工作量超过了评审者的预期。同时也存在一些极端状况，某些小的评审可能只应该几十秒就可以评审完毕，但是评审者在不知情的状况下却为它安排了大段的评审时间。

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

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

本文来自网络，如有侵权请联系网站客服进行删除

 您阅读本篇文章共花了：