【以下為分享實錄，有刪節】
阿里巴巴為什麼要自研代碼管理平臺
也許你會問：為什麼阿里巴巴要重新做一套代碼管理平臺，繼續用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內容，自動估算出評審耗時，並伴隨代碼評審通知一起來告知評審者，幫助他合理安排評審時間。以上能力會在用戶授權的情況下，陸續在雲效代碼管理平臺上開放給大家使用。
我們希望在不久的將來，開發者不僅將代碼託管到雲上，整個開發過程也可以搬到雲上。雲效代碼管理平臺（Codeup）目前正在以每週一個小版本每月一個大版本的速度迭代演進，在保證高可用、高性能、高體驗的同時，旨在給企業開發者和管理帶來更有價值的創新。目前所有開發者都可以通過雲效官網免費使用Codeup，也歡迎大家加入雲效開發者交流群（釘釘群號：34532418）來與我們交流討論。
【關於雲效】
雲效，企業級一站式DevOps平臺，源於阿里巴巴先進的研發理念和工程實踐，致力於成為數字企業的研發效能引擎！雲效提供從“需求 ->開發->測試->發佈->運維->運營”端到端的在線協同服務和研發工具，通過人工智能、雲原生技術的應用助力開發者提升研發效能，持續交付有效價值。
【雲效官網】https://www.aliyun.com/product/yunxiao
【公測指南】https://developer.aliyun.com/article/756207
【申請公測】https://devops.aliyun.com
【學習路徑】https://help.aliyun.com/document_detail/153739.html
【開發者社區】https://developer.aliyun.com/group/yunxiao
【精彩活動】雲效公測開啟 「產品體驗官」招募中~
https://www.aliyun.com/activity/yunxiao/Beta2020
歡迎掃碼加入雲效開發者俱樂部（釘釘群號：34532418）