CODING 在前兩天的 Kubecon 2019 大會上發佈了 CODING 2.0。這背後是 CODING 對研發管理和研發團隊組建的思考。從 CODING 成立以來，我們一直在探索“讓開發更簡單”的方式。把“讓開發更簡單”這個大願景進行拆分，具體到可量化的產品目標上去，實際上是希望通過工具的形式，可以減輕開發過程中的重複勞動，提高軟件交付的速度與質量。
雲端開發的初心
最開始做 CODING 的時候，腦海中的藍圖是開發者在這裏討論需求、佈置任務、寫代碼，改代碼，演示代碼，完成相關任務，整套的開發操作都在這裏。
所以當時的產品結構是：輕量級的任務管理 - 討論 - 代碼版本管理 - 演示平臺
在這套產品體系下，產品經理會把任務指派給設計師，設計師完成設計後，產品經理驗收後再把任務指派給研發人員，研發人員推送代碼後，可以在演示平臺做演示給產品經理驗收。這是一套非常適合小團隊的工作模型，流程簡單，反應快速，CODING 自己團隊也在使用，並且支撐了 CODING 產品前期的快速起步，快速上線，快速響應反饋的開發節奏。
企業在成長過程中碰到的實際問題
很快，隨着 CODING 業務的發展，CODING 的產品線越來越多，團隊也越來越大，當團隊到達 100 人的時候（其中 60% 都是研發），我們發現團隊開始"管不動"了，最終的上線質量非常依賴部門 Leader 的管理能力和開發者的自我修養。爲了保證產品達到預期，我們制定了大量流程和規範，但這讓我們的進度越變越慢了。我們一度非常苦惱，創業公司的優勢在於極高的效率與極快的產品迭代，但如果我們在發展的過程中丟失了這樣的優勢，將會很輕易的被別人超過。
所幸我們並不是第一個碰到這個問題的人。《人月神話》中有個很著名的觀點：
Adding manpower to a late software project makes it later.
– Fred Brooks, (1975)
“如果希望用增加人力的方式解決軟件的進度問題，只會讓進度變得更慢。”因爲：
溝通成本= n(n-1)/2 n=團隊人數
舉例而言 10 個人的團隊將有 45 個溝通管道，當人數到達 50 人時，這個數字將上升爲 1225 個。隨着人數的增多，團隊內的溝通成本將指數級上升。瞭解到問題出現的原因，也就知道了解決方案：“我們需要更多更小的團隊”——通過將團隊分成若干個內部閉環的小團隊來降低溝通成本。於是我們有了一個稍微敏捷一點的組織架構：
這個工作方式敏捷的很不徹底，問題在於運維。考慮到線上穩定性及系統的耦合程度，無法將運維拆到各個團隊中去，各個產品線雖然有獨立的產品經理、設計師和開發者，但需要運維協助上線測試環境，再由測試進行 testing 和 staging 兩個環境進行測試驗收。大量的時間被無用的等待浪費掉了。
同時，由於工作目的的不同，開發與運維的矛盾也日益加深，都覺得對方基礎的工作沒有完成。
團隊陷入了困境。
我們需要 DevOps
困境中醞釀着機會，我們在與用戶的交流中發現這也是大多數團隊的共同苦惱：**團隊如何組織才能最大化的進行軟件產出？**各個角色之間天然的目標不同，使得”又快又好的上線“變得困難重重。
DevOps 的理念就是希望能打破這種屏障，讓研發（Development）和運維（Operations）一體化，讓團隊從業務需求出發，向着同一個目標前進。DevOps 不只是通過工具輔助開發完成運維的部分工作，更是一種軟件研發管理的思想、方法論，所追求的是一種沒有隔閡的理想的研發協作狀態。
實踐 DevOps 的首要任務是需要對 DevOps 的目標和精神達成共識，並以此指導工作。據此，我們制定了從新的產品線開始逐步拆分微服務、優化白名單驗收機制等改進措施，並制定了明確的時間表。長期來看，希望在更好的保證軟件質量的同時，開發更少的依賴運維工作。
之後，團隊開始嘗試放大工具帶來的效能提升。雖然之前也使用了不少工具，比如用 Jenkins 在本地構建持續集成，自建 Docker Registry 做構建物管理，使用 Excel 進行測試管理等。但相對零散，培訓成本高，同時需要有人力進行選型搭建和維護，哪怕只放半個開發半個運維，一年也是小幾十萬的投入。
我們迫切的需要一套工具，上手即用，輔助我們提升研發團隊的產出效能，而不是花費人力時間在進行基礎設施的搭建上，但市面上完全沒有這樣的產品，我們的用戶也存在類似的苦惱，只能用好幾種開源產品進行搭建。
那 CODING 爲什麼不做一套這樣的系統，讓有同樣困難的 DevOps 轉型企業可以快速完成工具建設？“讓開發更簡單”作爲 CODING 一直以來的使命和願景，督促 CODING 團隊爲開發者提供更優質的工具與服務。加之 CODING 的核心業務——代碼託管是 DevOps 工具的基礎與支點，故從 2018 年年初起，CODING 就將產品目標調整至爲企業提供一整套的研發管理工具。在一年多的努力下，目前 CODING 已經全面開放持續集成功能及製品庫的 SaaS 版本的服務，支持所有主流語言以及多種目標環境。
DevOps 開發工具鏈：代碼即應用
我們認爲，在不遠的將來，隨着工具的成熟，我們將進入**“代碼即應用”（Code as a Product）**的時代，開發者無需進行繁雜的其他工作，僅需完成代碼編寫，應用就自動運行，企業因此降低了運維成本，提升了軟件研發部門的效率。
"代碼即應用”對工具的要求分三個階段：
- 持續集成階段：通過持續集成工具，運行設置好的執行命令，避免重複勞動。
- 自動化部署階段：構建的創建過程本身變得簡單，無需學習額外的運維開發知識即可創建應用的發佈方式。
- Serverless 階段：真正做到發佈無感知，代碼寫下即發佈。
CODING 2.0 上線了持續集成及製品庫的功能，標誌着 CODING 正式進入持續集成階段。用戶僅需推送代碼或合併請求，即可出發持續集成進行構建、單元測試、安全掃描等工作，並生成製品存儲在製品庫。提升軟件交付的質量與速度，同時減少因爲構建過程中引入“人”而帶來的不確定性。
除工具外，CODING 還爲企業提供研發流程實施的指導培訓、敏捷訓練等額外服務。目前已有幾十家企業將 CODING 的 DevOps 工具應用到內部生產中，大大提升了團隊 DevOps 轉型的效率。
還有點想說的
中國軟件行業發展時間短，發展速度快，人才儲備時間短，地位也比較尷尬，哪怕是軟件服務起家的互聯網公司，隨着公司的壯大，業務部門的地位也逐漸高於軟件研發部門。除了在少量領域，中國企業在這一過程中，研發部門的內驅力往往被消磨殆盡。加之軟件行業人力成本不斷增加，作爲支持和成本部門，管理者也容易將軟件研發部門視爲成本部門，思路往往是“能否降低成本”。
但如今，瞬息萬變的市場環境對軟件研發部門提出了很高的挑戰，這是困難但也是機會。一支高效的研發團隊，不光可以減少系統間的摩擦和浪費，讓研發部門快速響應市場需求，還可以持續交付高標準的產品，讓產品驗證進入正循環，引領整個團隊的價值實現。
但組建一支這樣的團隊，需要的遠不止是工具，更重要的是團隊領導者的經驗，知識，和變化的決心。許多有先鋒精神的團隊走在改革的前面，CODING 在協助他們轉型的過程中，也看到了他們因爲改革所碰到的困難、權衡和進步之後團隊爆發出的生產力。
我們希望可以看到更多的中國軟件企業瞭解 DevOps 的精神，並應用到自己的團隊管理中去，向中國和世界交付一流的軟件產品。這個過程很難，但真的很值得。
體驗 DevOps 全工具鏈敏捷研發
