Adding manpower to a late software project makes it later.
雲端開發的初心
最開始做 CODING 的時候，腦海中的藍圖是開發者在這裡讨論需求、布置任務、寫代碼，改代碼，示範代碼，完成相關任務，整套的開發操作都在這裡。
是以當時的産品結構是：輕量級的任務管理 - 讨論 - 代碼版本管理 - 示範平台
在這套産品體系下，産品經理會把任務指派給設計師，設計師完成設計後，産品經理驗收後再把任務指派給研發人員，研發人員推送代碼後，可以在示範平台做示範給産品經理驗收。這是一套非常适合小團隊的工作模型，流程簡單，反應快速，CODING 自己團隊也在使用，并且支撐了 CODING 産品前期的快速起步，快速上線，快速響應回報的開發節奏。
企業在成長過程中碰到的實際問題
很快，随着 CODING 業務的發展，CODING 的産品線越來越多，團隊也越來越大，當團隊到達 100 人的時候（其中 60% 都是研發），我們發現團隊開始"管不動"了，最終的上線品質非常依賴部門 Leader 的管理能力和開發者的自我修養。為了保證産品達到預期，我們制定了大量流程和規範，但這讓我們的進度越變越慢了。我們一度非常苦惱，創業公司的優勢在于極高的效率與極快的産品疊代，但如果我們在發展的過程中丢失了這樣的優勢，将會很輕易的被别人超過。
所幸我們并不是第一個碰到這個問題的人。《人月神話》中有個很著名的觀點：
-- 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 的精神，并應用到自己的團隊管理中去，向中國和世界傳遞一流的軟體産品。這個過程很難，但真的很值得。
點選使用 CODING 2.0
體驗 DevOps 全工具鍊靈活研發