CODING 2.0：爲何咱們須要 DevOps

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）的時代，開發者無需進行繁雜的其餘工做，僅需完成代碼編寫，應用就自動運行，企業所以下降了運維成本，提高了軟件研發部門的效率。

"代碼即應用」對工具的要求分三個階段：

1. 持續集成階段：經過持續集成工具，運行設置好的執行命令，避免重複勞動。
2. 自動化部署階段：構建的建立過程自己變得簡單，無需學習額外的運維開發知識便可建立應用的發佈方式。
3. Serverless 階段：真正作到發佈無感知，代碼寫下即發佈。

CODING 2.0 上線了持續集成及製品庫的功能，標誌着 CODING 正式進入持續集成階段。用戶僅需推送代碼或合併請求，便可出發持續集成進行構建、單元測試、安全掃描等工做，並生成製品存儲在製品庫。提高軟件交付的質量與速度，同時減小由於構建過程當中引入「人」而帶來的不肯定性。

除工具外，CODING 還爲企業提供研發流程實施的指導培訓、敏捷訓練等額外服務。目前已有幾十家企業將 CODING 的 DevOps 工具應用到內部生產中，大大提高了團隊 DevOps 轉型的效率。

還有點想說的

中國軟件行業發展時間短，發展速度快，人才儲備時間短，地位也比較尷尬，哪怕是軟件服務起家的互聯網公司，隨着公司的壯大，業務部門的地位也逐漸高於軟件研發部門。除了在少許領域，中國企業在這一過程當中，研發部門的內驅力每每被消磨殆盡。加之軟件行業人力成本不斷增長，做爲支持和成本部門，管理者也容易將軟件研發部門視爲成本部門，思路每每是「可否下降成本」。

但現在，瞬息萬變的市場環境對軟件研發部門提出了很高的挑戰，這是困難但也是機會。一支高效的研發團隊，不光能夠減小系統間的摩擦和浪費，讓研發部門快速響應市場需求，還能夠持續交付高標準的產品，讓產品驗證進入正循環，引領整個團隊的價值實現。

但組建一支這樣的團隊，須要的遠不止是工具，更重要的是團隊領導者的經驗，知識，和變化的決心。許多有先鋒精神的團隊走在改革的前面，CODING 在協助他們轉型的過程當中，也看到了他們由於改革所碰到的困難、權衡和進步以後團隊爆發出的生產力。

咱們但願能夠看到更多的中國軟件企業瞭解 DevOps 的精神，並應用到本身的團隊管理中去，向中國和世界交付一流的軟件產品。這個過程很難，但真的很值得。

點擊使用 CODING 2.0
體驗 DevOps 全工具鏈敏捷研發