本文為 CODING 研發總監 王振威，在騰訊雲 CIF 工程效能峰會上所做的分享。
文末可前往峰會官網，觀看回放並下載 PPT。
大家好，我是王振威，CODING 研發總監。非常高興能在這裡給大家分享過去一段時間 CODING 的產品思考和升級，併為大家介紹 CODING 戰略升級後的重磅新品。
首先，我們來看一下 CODING 的全景產品矩陣。這裡標識出了過去一年裡， CODING 做出的重要產品更新，其中有大量產品是全新推出的，也對一些現存的產品進行了升級，這張圖幾乎囊括了 CODING 現存的所有重要產品模組和功能。我們聚焦於軟體研發階段的管理，從團隊協同到專案計劃，從程式碼協作到構建整合，從測試管理到製品管理和部署上線，在部署上線後就完整對接了雲基礎設施 IaaS 和 PaaS，這樣就可以理解為，如果客戶使用了 CODING 並且使用了雲，就可以形成一套全鏈路的雲原生體系。
在過去一年裡，CODING 堅持以客戶為中心，朝著讓開發更簡單的方向，面向雲原生的未來產業大規模增強了既有的產品，並打造了一些非常激動人心的新品。我將在接下來重點介紹一些其中的新品和重要的產品升級。
專案協同 2.0 —— 有條不紊
我們都希望所有的事情進展，都是按照有序的節奏來進行。那麼我們知道，軟體開發工作是高度複雜的，這需要各種不同型別的專業人員的協同，例如：產品經理、後端工程師、測試工程師、前端工程師、敏捷教練、UI 設計師等等，不同的公司也有不同的角色設定。但如果僅僅只是簡單地把這些人員湊在一起，缺乏一套確定的工作交流機制，我想他們的協作將陷入一團亂麻。
CODING 面向開發者團隊提供的專案協同，一直都是我們產品的重中之重，專案協同產品團隊剛剛完成了產品的 2.0 重大升級，希望讓協作有條不紊。這裡我將簡要介紹幾個專案協同 2.0 的重要特性。
第一是新增自定義協作模式。我們都知道，專案管理軟體鋪天蓋地，可能有非常多的選擇，但傳統的專案管理軟體往往都是基於某一種特定的管理理論，比方說敏捷或是瀑布，針對某一種具體場景來深入設計。事實上這種設計方式明顯缺乏靈活性，對於大多數企業而言，企業內部的事項往往無法被精準的歸類為「需求」、「任務」或者「缺陷」。
例如對於一個金融企業來說，他可能需要管理「風險」這一概念；而對於初創企業來說，新的產品還沒有完備的產品需求，他可能需要一個概念叫做「構想」或者「腦洞」；對於一個軟體企業來說，可能專門有一類任務叫做「交付」或者「實施」。那麼你可以看到，事實上不同的企業沒有辦法使用傳統的專案管理軟體裡的概念，來表達自己的業務模型。
不論是「風險」、「構想」還是「交付」，專案協同 2.0 都可以非常靈活的應對，使用自定義協作模式不僅可以跳出敏捷和瀑布協作模型的限制，更可以自由依據企業的實際業務來具象化工作項的概念。風險這樣的自定義概念不僅可以設定文字、數字、單選框等常規屬性型別，專案協同 2.0 還支援非常多的內部資訊關聯。例如你可以設定一個腦洞的提出人為專案成員中的一個成員，甚至可以設定一個腦洞的預計實現週期為哪幾個迭代。這些自定義的概念和自定義的屬性，再配合自定義的流程，一套專屬於企業自己的專案協作流程就完整建立起來了。
其中事項的狀態也可以進行自定義，比如企業可以根據自身的情況，為不同型別的工作項設定如產品評審階段、設計評審階段、架構評審階段、開發中、已測試、待上線、已釋出等任何狀態。如果新定義一個概念為「風險」，那麼可以為「風險」設定：已發現、已識別、評估中、處理中、已消除等等不同的狀態。並且這些概念在不同狀態間轉移時，我們可以定義其轉移規則，設定只有某類成員可轉換某個狀態，例如只有測試人員可以把「開發中」的任務轉移到「已測試」狀態，這給企業事項流轉流程帶來了非常大的靈活性和便利性。
第二個是專案協同 2.0 帶來的全新的專案集功能。專案集是用於管理在專案層級之外的跨專案事項進展。如圖所示，專案集裡的需求可以分解到不同團隊的不同專案裡，並可以在專案集檢視進行集中管理和追蹤。
下圖是一幅經典的專案集頁面資訊，可以清楚的看到與專案不同，專案集有明確的時間期限，會設定若干個里程碑，整個專案集的里程進度在這裡一目瞭然。此專案集裡的任務在不同專案裡的進度也記錄的非常清楚。從專案集的推動者角度來看，如此透明的資訊和明確的時間進度規劃，可以高效推進跨團隊的協作，有效解決企業部門牆問題。
時間有限，專案協同 2.0 新升級的特性就介紹到這裡， 其他方面的功能和體驗這裡就不再一一列舉。我們相信，高度靈活的屬性和流程配置，清晰直觀的資訊展示，規則透明的流轉設定，可以讓協同有條不紊。專案協同 2.0 的全部功能特性已經可以在 CODING 公有云（coding.net）上體驗，有私有化訴求的客戶和合作夥伴可以與我們聯絡。
持續部署 2.0 —— 得心應手
伺服器軟體的釋出從來都是一個非常困難且複雜的問題，針對這個問題行業內有非常多的做法，從我們的角度來思考，這個過程其實是銜接 DevOps 中 Dev 和 Ops 的關鍵環節。但事實上開發者和運維者的關注點是有差異的，開發者要快速交付，而運維者更關注穩定可靠。DevOps 其實難以調和這種矛盾，但通過重塑職責，讓運維者專注於執行設施運維，而讓開發者承擔業務運維；讓開發者權責合一，有權釋出並檢視目標環境的程式以及他的關鍵資訊，並且讓開發者承擔起對應業務的穩定性責任。做到這樣，釋出才能真正得心應手。
CODING 持續部署 2.0 正是圍繞著這一目標完成了全方位升級，首當其衝的是應用控制檯。把開發當做左側，運維當做右側來看，那麼我們希望實現業務運維的權力和責任完整轉移到開發身上，也就是運維左移。開發人員與運維人員的關注點不同，開發人員是應用思維，運維人員是資源思維，那麼要做一個支撐開發人員全面接管應用業務運維的功能，就必須以應用為中心出發。
在應用控制檯，對應的開發團隊可以非常方便地看到關注應用的釋出歷史、環境列表、監控狀態和對應的日誌記錄。開發人員不再需要去找運維人員查詢日誌，也不再需要藉助運維人員的幫助才能增加一條條告警規則，真正實現了讓運維專注於資源設施，而開發者專注於應用。
開發測試完畢的軟體需要釋出才能真正為使用者提供服務，釋出階段的風險也隨之而來。雖說絕大多數的釋出都是以程式本身的版本升級為主，但實際情況是，大量的釋出過程還夾雜著不可控的資料庫變更和配置項變更，這種情況往往被大量忽視。過去的持續部署，幾乎所有的軟體和實施團隊都只關注於應用程式本身的變更，這導致實際的釋出場景還是需要大量的人工介入。CODING 持續部署 2.0 提出了多維度釋出概念，能將程式、資料庫等外部服務、配置項等等的相關釋出整合成有機整體，全面接管釋出過程，真正實現釋出過程全自動化。
另外一項重要的特性是，我們實現了 GitOps 理念。GitOps 是近兩年非常流行的一種運維實踐，因部署工作屬於運維的一部分，自然 GitOps 也能解決部署的問題。GitOps 通過 Infrastructure as Code（簡稱 IaC）為基礎， IaC 把目標環境的基礎設施和程式的狀態都描述為程式碼，並儲存於 Git 倉庫中。在這種情況下，對目標環境的變更不再是由運維直接操作目標環境，而是通過修改 Git 倉庫中的程式碼，再由 GitOps 體系完成程式碼與目標環境的自動同步。基於 Kubernetes 的應用可以非常方便的實踐 GitOps，因為 Kubernetes 本身就設計為支援宣告式定義和終態控制，再配合 YAML 檔案定義的 Git 倉庫，釋出變得得心應手。
CODING 當前已經提供了完備的實踐 GitOps 的能力，用 CODING 程式碼倉庫管理 IaC 原始碼檔案，用 CODING 合併請求審查環境變更，由 CODING 持續部署完成原始碼與環境同步。
CODING 持續部署 2.0 已經可以接受早期使用者的試用申請，可進入 CIF 重磅釋出頁瞭解並體驗新品。
Nocalhost —— 化繁就簡
正如前面講過的一樣，伺服器軟體的釋出是複雜的，雲原生這一解決伺服器軟體架構問題的概念，在當下階段也是相當複雜的。這種複雜性不僅僅體現在基礎設施和運維工作上，它也傳遞到了開發編碼階段。微服務架構的應用經常由幾十上百個微服務組成，這些微服務在程式邏輯和維護的人員團隊上都分工明確。但如此鬆散的組織，給開發編碼自測帶來了巨大的挑戰。
CODING 於 2020 年底推出了開源雲原生開發環境 Nocalhost。我們希望在雲原生時代，開發者可以讓雲原生微服務編碼體驗像單機應用一樣原始而又純粹。雲下的微服務開發體驗是糟糕的，開發者不能也不願把整套微服務執行起來，既然沒有一個完整的開發測試環境，也就無法方便地進行自測和除錯；如果執行全部微服務，則需要消耗大量的資源，且難以維護；本地化的執行與實際的容器環境差異過大，往往會導致後續問題的爆發。Nocalhost 此次重大升級，從除錯、環境準備等方面進一步簡化了雲原生開發編碼的複雜性，讓編碼化繁就簡。
使用過 Nocalhost 的開發者都知道，當前開發的微服務是執行在遠端容器叢集裡的。這在某種程度上極大的保障了開發自測環境與最終目標環境的一致性，也極大的節約了本機計算資源。但是在這種情況下，想要便捷除錯執行在遠端容器的程式，並不是一件容易的事情：原始碼在本地電腦，程式卻在遠端容器中，想要除錯必須進行一系列複雜的網路打通和 IDE 配置。Nocalhost 此次升級新增了一鍵除錯功能，開發者只需要在對應的微服務上點選除錯，等待幾秒鐘，IDE 就會進入除錯模式。
如下圖所示，左邊是目標網頁的執行效果，右邊是微服務的原始碼。開發者只需要在對應的程式碼行設定斷點，並去網頁端觸發請求，當斷點到達時，就可以自由的控制語句執行和變數計算等除錯過程。所有事情都由 Nocalhost 完整解決。
開發體驗中另一個讓開發者痛苦的事情，就是等待服務啟動的過程。比如寫完一段程式碼，點選重啟，等待啟動完畢，才能重新整理頁面看到結果。 重啟過程對於一些服務來說可能是以分鐘計量的，這時你突然發現自己寫錯了一個字母，需要再重啟一下等待幾分鐘才能看到結果，此時你的內心可能是崩潰的。
其實不同的語言和框架都提供了實時熱載入的能力，但本地原始碼與雲上容器裡的程式天各一方，使得這些語言和框架提供的實時熱載入能力，大多數情況下都無法使用。Nocalhost 再次化繁為簡，免去複雜的配置和原理理解，讓實時熱載入真切地增強編碼體驗。開發者在 Nocalhost 中找到對應的服務，右鍵點選遠端啟動，然後等待啟動完畢，僅需一次，之後就可以愉快寫程式碼了。開發者唯一要做的就是寫程式碼，並儲存檔案，然後重新整理頁面看結果就行了。
在規模巨大的微服務架構應用中，開發階段存在著兩個難以調和的矛盾。要想讓開發者開心地編碼，那麼最好給每位開發者都提供一整套完整的微服務架構應用開發環境，而這非常浪費計算資源，成本也居高不下。要想節省計算資源，則只能想辦法提供若干套固定的開發測試環境，給開發者共享使用，而當多個人在一個環境裡同時開發、除錯、測試會造成環境的混亂，開發者的開發自測節奏會被嚴重干擾，最終效率大為下降。
Nocalhost 此次重大升級實現了構建在基礎環境之上的邏輯環境，環境裡的微服務元件通過邏輯劃分組成虛擬環境，既節省資源，又能讓不同的開發者之間相互隔離。如下圖所示，假設某個應用是由 ABCDE 五個微服務組成。我們執行這些微服務，並保持其功能和版本的穩定，設定為基礎空間。如果有個開發者希望開發 A 服務，而他並不關心 BCDE 四個服務，那麼只需要給他一個邏輯空間，也就是一個專屬的開發空間，這個空間裡只包含用於開發測試的 A1 服務，並複用基礎空間的 BCDE 即可；另一個開發者也需要開發 A 服務時，可以給他建立一個 A2 服務，並跟其他的 BCDE 一起組成一個專屬的開發空間；另一個開發者或小組需要開發 C 和 D 兩個服務，那麼只要共享 ABE 就可以。在這樣的節奏下，每個開發者都能擁有完備的五個微服務，而不用每人都實際執行一整套服務。上述這套機制的原理是複雜的，實現也不容易，但 Nocalhost 化繁為簡，只需要使用者指定基礎環境，並設定開發空間中需要用的微服務元件，即可搞定一切。
在下圖可以看到，正常的流量被標記為藍色，會被基礎空間的服務處理並返回撥用者。而專屬於開發者（小明）的流量會被標記為綠色，傳輸到小明專屬的開發空間，處理完畢後再返回給呼叫者。這個染色和流量排程是藉助於 Tracing 和 Service Mesh 實現的，但使用者不需要了解細節，直接設定就可以使用。
Nocalhost 是完全開源的產品，並計劃於今年捐獻給知名開源基金會，以促進行業整體發展。上述介紹的功能都可以在 Nocalhost 官網（nocalhost.dev）檢視對應的使用文件。
研發度量 —— 清晰瞭然
我們所處的世界正在經歷巨大的數字化浪潮，從工業到農業，從科研到生產，從消費到娛樂，以計算機和軟體為核心的技術正在用資料度量整個世界。然而對於軟體本身的生產過程來說，數字化程度反而不高。這體現在軟體生產過程不透明，階段進度無法量化，很難用數字來歸因成敗，難以實施瓶頸分析。軟體開發是一項工程，成熟的工程不該是現在這個樣子，我們認為成熟的工程應該是可度量、可量化、可追溯、可分析的，軟體開發過程本身的資料不夠清晰，就會導致上述問題，最終難以管理。
CODING 全新推出研發度量產品，讓研發資料清晰瞭然。
CODING 專注於軟體研發過程的管理和效率提升，要想讓研發過程的資料清晰瞭然，就必須全鏈路收集資料。我們從工作事項、開發編碼、測試驗證、構建整合、釋出部署五個階段把關鍵資料指標進行歸類與收集，並依據大量的行業調研和案例分析，設計了關鍵資料項。全鏈路的關鍵項資料捕捉確保整個度量體系能掌握要點，同時高度開放的可擴充套件性，確保了單項的深度延伸。
化繁就簡一直都是 CODING 的重要特性。在五大階段多達幾十上百項資料，又區分了專案，時間視窗，人員等多個維度，這些資料非常繁雜，但研發度量可以做到極簡配置，大多數資料都可以以推薦方式一鍵生成資料檢視。如下圖所示，針對事項計劃、人力排版等問題，研發度量也給出了專門的面向人員的人力飽和度檢視；在多人合作，多工並行，常規任務與突發任務混雜的情況下，可以一目瞭然地瞭解到每一個人員的工作安排計劃。而這項能力的構建必須要求全面的資料收集。
我們通過大量的資料和案例分析，總結了一套研發過程數字化深度，和團隊研發效能的成熟度模型，這套模型直接內建到了 CODING 研發度量內部。對於使用者來說，關注這些重點指標就可以瞭解自身的效能成熟度狀況，取長補短，有針對性地優化自身流程和能力，最終取得事半功倍的效果。
當前，研發度量已經全面上線 CODING 公有云，使用者可以即刻進行體驗。有私有化訴求的客戶和合作夥伴可以與我們聯絡。
Compass —— 行雲流水
經過分析研發度量收集的大量研發過程資料後，我們一直在思考軟體工程的終極形態是什麼？我們曾經拿軟體工程和建築工程類比，又拿軟體工程與智慧製造類比，還拿軟體工程與科研類比，還廣泛接納《程式設計之美》這類把程式設計視作藝術的思維。我們的結論是它們有點像，又不完全一樣。
終究，軟體工程仍然是一項工程，應該具備工程的關鍵特徵，如流程，進度，質量，風險等。然後在工程基礎上疊加軟體的特性，如並行協作、迭代更新等。
每一個軟體開發團隊都有自己的特殊情況，但他們都希望團隊有規範流程，協作順暢。CODING 全新推出了 Compass，把我們對於軟體工程的深入思考、流程規範的最佳實踐、價值交付的核心思想完全內建到了這個產品中。我們相信，軟體工程是需要規則規範的，規則規範的設定不僅僅是在單點上體現最優的狀態，從全域性角度來看也一定是高效的。Compass 為軟體工程指引方向，讓研發行雲流水。
作為我們對軟體工程終極思考的答案，我們為這一橫跨全鏈路的規範執行方式和價值交付流，取名為：Compass。Compass 是羅盤或指南針的意思，我們希望從事軟體研發的成員可以被 Compass 指明前進的方向，而不是靠同事或者領導來安排工作。一個精密運轉的軟體研發過程，應該由系統依據規範和流程來告訴人們他們該幹什麼，而不是讓人盲目的去尋找工作的方向。
流程是 Compass 的核心。對於一個研發團隊來說，要想設立高效的研發規範，首當其衝的任務，是確認自己團隊以什麼樣的流程開發交付軟體。Compass 的流程引擎高度靈活，可編排從專案的工作項，到程式碼分支合併規則，到原始碼質量規範，到構建測試紅線，到製品儲存結構，最後延續到釋出交付流程。
可以說 Compass 設立了一個研發全鏈路的流程定義，這個流程一旦定義之後，便可非常方便地強制研發團隊內的成員，遵照流程來執行工作內容，進而符合規範。我們相信明確的流程會給到明確的預期，也將產生結構化的精準度量資料。對於研發團隊來說，其中的每一個角色都會得到一份 Todo List，這份 Todo List 是 Compass 根據流程的執行節點自動計算得出的，每一個成員只需要不斷去完成 Todo List 中的事項，整個流程就會行雲流水般自動推進。
例如一個開發者早上起來開啟電腦，看到 Compass 列出的 Todo List 中清晰寫明，他有三項編碼任務，兩項程式碼評審任務，一個釋出審批確認待處理。他完全可以依據系統資訊瞭解到每條任務的上游基本狀況，也可以根據流程推算了解到任務完成時間對下游的影響。如此清晰的工作指引，就好像時時刻刻都有一個羅盤在指引著工作方向，所有的這些事情，都由系統全自動驅動人往前走。在這樣的基礎上，可以理解為，我們把軟體的生產過程近乎轉化成了製造業的車間流水線，流水線的工人唯一要做的事情，就是等待上一個步驟的產出物並進行自己的加工，最終交付給下游進行進一步加工。
由於流程驅動著人推進事務進展，每一個階段的啟動和完畢都被系統記錄在案，全部資料會統一上報到研發度量體系內部，管理人員可以很方便地進行瓶頸分析。例如發現過去一個月總是在測試這一環節消耗太多時間，則可以仔細分析，看是人力不夠，還是測試工具落後，亦或是人員懈怠。
結構化、流程化、數字化、規範化的研發過程產生了大量實際資料，而這些資料又反過來用於優化研發規則和流程的設定，形成雙向正迴圈，使得流程和規範本身也像產品一樣迭代起來，企業的研發效能才能真正步步為營，逐漸提高。從這個角度上說，Compass 把敏捷迭代的思想從軟體的產品研發延伸到了管理制度。
由於每一項具體的事項都有具體的規範準則，這可以非常直觀便捷地約束操作者的行為，這為 CTO、CIO、技術委員會、架構支援部門等核心技術組織，在全企業貫徹技術實踐提供了強有力的保障。例如我們都知道 Git 倉庫的分支模型場景比較多，而 Compass 單單針對分支合併這一場景，就可以細緻化地設定分支命名規則，合併流程，合併許可權，事前檢查，事後通知等等。諸如此類，我們希望讓研發過程中的所有關鍵環節都有章可循，最終實現按圖索驥的效果，讓 CTO 的技術管理從口頭上的諄諄教誨升級為系統的約束準則。
Compass 是 CODING 在軟體工程上思考的終極答案，我們希望把軟體研發打造成行雲流水的工廠流水線。最終效果是機器推著人往前走，而不是人推著機器往前走。Compass 在 CODING 體系內是凌駕於其他全部產品模組之上的，是一個全域性性的、非常龐大的產品體系。當前 Compass 最核心的流程引擎已經打造完畢，大家可以訪問 CIF 大會重磅釋出頁瞭解 Compass 的更多功能特性和適用場景，並申請試用。
還有更多……
CODING 過去一年產品迭代碩果累累，由於時間有限不再一一贅述，這裡列舉一些關鍵更新——
-
CODING 即將推出騰訊自主研發的 CI 引擎，以解決長期受制於 Jenkins 帶來的不便。這款引擎已經在騰訊集團內部使用多年，久經驗證，功能強大，使用靈活。新的引擎將配合騰訊雲安全容器實現更快的排程，更靈活的編排能力。CODING 新的 CI 引擎當前已經可以接受早期使用者的試用，可進入 CIF 重磅釋出頁瞭解和體驗新品。
-
CODING 於 2020 年釋出了獨立部署的製品庫： WePack。當前 WePack 充分融合了騰訊集團的安全能力，與業界知名安全團隊雲鼎安全實驗室和科恩安全實驗室強強聯合，大幅增強了 WePack 在製品掃描，安全加固等方面的能力。WePack 不僅可以使用行業公開的漏洞庫掃描製品，比如大家耳熟能詳的 NVD、CNVD 等，還擁有騰訊安全團隊 20 多年的能力積累，自主可控和深度安全的能力在過去一年獲得了眾多金融客戶的認可。WePack 可以便捷私有部署在客戶的環境內，更多的資訊可以進入 CIF 重磅釋出頁瞭解體驗新品。
-
CODING 基於 Git 程式碼庫增強了基於目錄的讀寫許可權控制。從 SVN 遷移到 Git 的團隊往往都在抱怨 Git 無法在目錄層面上控制讀取許可權，瞭解過 Git 原理的人都知道，Git 是基於整個程式碼庫雜湊的演算法來進行版本校驗的，如果檢出的檔案不齊全，將無法完成校驗，這個基本原理導致 Git 本身無法實現按目錄的讀取許可權控制。CODING 從原理出發，對 Git 進行了擴充套件，在相容現存的 Git 用法且不侵入 Git 的基礎上，通過擴充套件 Git 實現了按目錄的許可權控制。這項能力當前已經可以接受早期使用者的試用，可聯絡我們申請試用。
-
Cloud Studio 團隊大幅改進了雲上 IDE Cloud Studio 的體驗。Cloud Studio 現在變得更方便、更快捷，同時便捷程度已經超越本地 IDE。開發者不需要安裝任何軟體，只需要開啟瀏覽器，登入自己的賬號就可以開始程式設計。從開啟一個雲上的工作空間開始，到工作空間完整可用僅需要 3 秒便可載入完成。新版 Cloud Studio 目前已全面上線，可前往官網（cloudstudio.net）註冊使用，如有私有化部署需求，可與我們聯絡。
CODING 希望打造全鏈條的雲原生開發體系，在此由衷感謝客戶、合作伙伴、同行給予的支援和幫助。雲原生開發體系當前還很不完備，CODING 要走的路還有很長，我們期待未來全面的雲原生時代到來後，開發更簡單！
