一、蒸汽時代

為了能快速讓團隊步入正軌，商米研發團隊早期采取和大多數企業類似的組織方式，以職能為單位的進行團隊劃分，分為前端、后端、Android端、測試、產品等職能團隊，并采用傳統瀑布研發模式組織團隊協作。當時，我們稱之為正規的研發模式。

每個團隊由組長負責制，具體負責團隊任務的分配、技術決策和人員培養，組員負責具體的研發任務。根據這樣的職能協作的方式，商米建立了早期的研發流程：

1. 產品經理進行原型圖設計。

2. 然后產品經理，分別找各個組長請求人員支持。

3. 組長根據自己團隊人員工作現狀，將工作安排給相應的同學，接手產品開發任務，完成工作量評估、給出截止時間等。

4. 最后在各自團隊的同學，完成相應的工作之后，大家約好一個時間，集中聯調一下，再交付給測試團隊。

職能團隊的組織方式，幫助商米走出了第一步。但是彼時，工程能力方面，卻是一窮二白，別說CI/CD了，連部署工作都還是手工FTP上傳文件，來進行服務器的發布。

沒有專門的運維團隊，服務器運維工作一直是后端團隊承擔，發布又是一個很重要的動作，出不的半點差錯，只能讓后端組組長進行發布，當業務不斷發展，項目數量不斷增多，負責發布的那個同學苦不堪言。

沒有專業運維團隊，沒有現成的工具。只能硬著頭皮去網上胡亂找一通，Jenkins太復雜，最后好不容易找到了一個簡易的工具，解決FTP上傳的問題，但最后的發布還是人工進行。

無論是協作效率，還是工程能力上，這種老牛拉破車的狀態，逼著商米團隊進行轉變。

小結：

通過建立職能團隊，產品經理對接職能團隊，尋找開發資源，以瀑布方式組織交付；工程能力方面，采用FTP純手工上傳方式進行發布，無專業運維團隊。

團隊的不斷增長和快速發展的業務，又帶來了新的挑戰。團隊間協作依賴，團隊成員業務歸屬感差；同時，因為手工為主發布軟件，通宵發布不是一件稀罕事。

無論是協作效率，還是工程能力上，這種老牛拉破車的狀態，逼著商米團隊進行轉變。

二、電氣時代

在尋找解決辦法過程中，商米引入Scrum研發模式，嘗試將職能團隊改造基于業務線的跨職能團隊：

• 資源獨享，組建獨立業務交付團隊，每個團隊都包含產品、測試、后端、前端、Android端，跨職能。

• 采用Scrum工作模式，引入Scrum Master 和四次Scrum會議（計劃會、每日站會、評審會議、回顧會議）。

跨職能團隊恰好能解決當時商米遇到的團隊協作上的問題，但卻無法兼顧職能團隊的優勢，于是增加技術委員會團隊來支持業務交付團隊：

通過敏捷化演進，在團隊協作上"虛線"和"實線"發生了變化：

這種方式同時給SUNMI帶來了另外一個改善，在成員評估上可以綜合成果產出、工作狀態以及技術能力多方面做出較全面的判斷：

• PO：評估團隊成員的業務成果的貢獻。

• SM：評估團隊成員配合過程中的積極性，響應速度。

• 委員會：評估團隊成員的技術能力和技術水平。

如組員張三的轉正評估：

為了更好的進行跨地域協同，數字化研發活動，在協作工具上，商米引入敏捷模板，能夠對Sprint進行規劃，并且能夠對迭代數據燃盡圖進行分析。

在缺陷管理方面也從Mantis切換到云效缺陷管理，和任務無縫關聯。

同時，在文檔協作上引入Thoughts工具，建立了完善的知識庫體系。

研發協作模式的改變，給團隊在協作效率和節奏上帶來了真正的好處。團隊再也不覺得自己是草臺班子了，而是真正具備一家科技公司該有的樣子。這是技術團隊，在管理模式上的一次重大升級。

小結：采用以業務為導向的跨職能團隊，有效解決職能間協作的依賴問題，同時增加團隊的業務歸屬感；以技術委員會，從職能角度組織人員培養和技術決策；落地Scrum研發模式，讓團隊形成節奏感。

商米經過敏捷轉型，解決了部分問題，支撐了團隊規模和業務體量的進一步擴大，進入了新一輪增長期。除了支持企業內部的研發發布，同樣商米也在構建自己的研發生態圈，按部就班的研發方式，顯然難以應對當前業務的復雜性和不確定性，體量越來越大。

同時，隨著產品服務化之后，服務的數量持續增加。業務復雜性，團隊規模，還是技術的復雜性和耦合性，都給整個協作和發布效率帶來了巨大的麻煩。

看似繁華的背后，卻有著道不盡的辛酸：

1. 發布流程不規范

   • 發布頻次低，流程長，時間久。

   • 人工介入多，容易出錯。

   • 漏測、搭車現象頻繁。

   • 沒有驗證完，還不愿發的被發布了。

   • 每兩個月就有由于流程原因導致的故障。

2. 信息同步不準確不及時

   • 任務的工作狀態與發布流程割裂。

   • 線上的事情線下做約定。

   • 是否發不清楚，發到哪里不清楚。

   • 不知道具體應用什么時候有誰做過發布。

   • 各角色、各系統之間的信息分離。

3. 檢查及測試手段匱乏

   • 無檢查無驗證卡點，測試后置。

   • 檢查驗證手段有限，測試手工兜底。

   • 每次發布，驗證周期時間很長。

   • 代碼評審集中在少數人，有瓶頸。

   • 代碼評審成為做樣子。

   • 漏發、漏測。

4. 公地危機，環境問題

   • 環境被長期占用，總是不夠用。

   • 環境有臟東西，不清楚是什么。

   • 每次發布，對業務有影響，停機發布。

如何破？成了商米技術管理者面前的一道難題。

三、高鐵時代

加速：交付加速的基礎發布方式的提升

一個偶然的機會，接觸到阿里巴巴云智能的云效團隊，我們決定聯手解決商米當前面臨的難題，經過分析，發現問題主要集中在以下幾個方面：

1. 返工：批量的集成，容易造成整個版本的失敗，每次失敗，所有的變更都跟著發不了。所謂，一粒老鼠屎，壞了一鍋湯。

2. 阻塞：手工工序過多，形成等待、阻塞；依賴過多，等待其他的部署。

3. 落后的技術：手工測試，流水線手工串接及觸發，信息同步靠口口相傳，純手工維護所有文檔。

4. 債務：無測試自動化，無有效的代碼掃描手段，無單元測試，應用間耦合高。

分析完這些問題，在云效團隊的幫助下，我們分別從整個流程和每道工序上進行了優化。

通過云效商米解決了工程效能的問題：

第一步：自動化部署流水線，釋放運維人力。一是對部署能力上，進行自動化改造，不再讓發布成為瓶頸，團隊想發就發，發失敗了也有相應的自動化應急措施。另一方面，在整個流水線上，通過流水線模板，快速創建了自己的流水線，并同時進行了改造，保存為企業自定義的流水線模板，這樣，當有團隊需要用到流水線時，自動從模板上復用下來，減少了配置和推廣的成本，默認從同一個模板上生成的流水線，在規范上是一致的。

第二步：建立質量保障機制，建立質量卡點，防止低級錯誤漏出；完善代碼掃描、單元測試，從源頭控制質量；同時，通過流水線的Jenkins插件，把我們之前基于Jenkins job的測試任務對接進來，完善掉測試屏障。

同時，靈活卡點設置，根據團隊業務情況動態配置研發流程。

與此同時，我們直接采用代碼平臺提供內建的代碼規約掃描和安全敏感信息掃描，從實際上的效果來看，直接在配置上打開就可以了，還不錯。如果采用非主流的開發語言，可以把掃描作為流水線當中的一個階段任務，對接進來就可以了。

Code Review的能力同樣采用了代碼平臺內置的功能，代碼的瀏覽和主流的云上編輯器差不多，可以單行給Comments，并且可以將Code Review設置為強制卡點。團隊Code Review的實踐很容易在這個工具下進行。

我們早期維護了一些自動化的測試用例，一直都是通過Jenkins Job進行運行的，采用流水線之后，通過流水線的Jenkins插件，也把之前的測試用例給跑起來了。

第三步：通過流水線的編排能力，為業務交付團隊提供發布部署順序上的編排，由業務交付團隊自行控制發布的時間、順序。團隊不再依賴專職的運維同學幫助發布軟件。運維團隊也逐漸從發布工程師，慢慢往SRE的路上發展。而之前，都是需要開發工程師反復寫好發布的說明，由運維去執行。

第四步：整個流程可視化，發布狀態實時感知，日志完善方便研發排查問題。

我們聽過很多的方法，接觸過許許多多的實踐，但畫在PPT上的流程難以落地，寫在書上的方法離我們太遠。技術人在意的是實實在在解決問題，將流程和方法，內建在工具上，是這次轉變的最大收益。

真正做到流程工具化、過程自動化、反饋數字化。工程能力的巨大的提升，同時進一步促進了協作方式的轉化。

工程能力建設作用于協作方式的轉變

由于開發和運維在工作流程上割裂的原因，在團隊協作看板上，也是割裂的，彼此完全基于不同的單元在組織工作。

兩周的迭代，第一周，需要主要集中在團隊開發看板上，第二周，發布請求主要集中在運維發布看板上。

Scrum Master在開發團隊的看板上剛組織完需求協作：

又得到運維看板上去協調發布請求，并且建立發布請求與需求之間的關系：

當發布工作完全由團隊自行決定后，團隊可以自行控制發布節奏，很自然地融合了開發看板及運維看板，形成完整的需求交付生命周期，基于需求組織交付協作。

引入云效DevOps工具，工程師可以直接從需求/任務卡片上創建變更分支，自動就將代碼變更與需求/任務卡片進行關聯，代碼變更的提交，同時自動地觸發的流水線，流水線的狀態也同樣會顯示到開發看板中，大大減少了信息同步過程花費的時間。

真正做到基于一個團隊開發看板，就能可視化代碼變更、發布流程所有信息，將隱性的工作顯性化，進一步簡化了信息同步，促進了協作。

• 每日站會，開發者基于云效進行需求或任務指派。

• 開發者基于需求/任務，自動創建變更分支。

• 將需求的代碼變更提交到變更分支，采用內置的代碼規約和安全掃描，完成代碼檢查，并發起代碼評審。

• 代碼評審通過，自動觸發發布流水線。

• 中間所有的代碼變更、發布流水線狀態，全都自動同步到需求/任務卡片上，保證需求上匯集協同所需要的全部信息。同時釘釘機器人將發布過程中的任何問題，自動推送給開發者，完全精確反饋。

商米引入云效工具再加上協作方式的改變，為整個商米軟件研發效能帶來了巨大的提升，真正意義上的進入了“高鐵時代”。從過去每周兩次的發布窗口期改善為隨時可交付，部分團隊甚至一天可以進行三次交付，大幅節省了運維發布時間，不再依賴人工操作和當面溝通，團隊內部可以在一個TB看板內關注到需求交付的全過程。

小結：優化部署流水線，按工序持續完善質量保障，為持續交付建立工程能力基礎；同時，工程能力的提升，也促進協作方式的改進。

三個階段小結：

從DevOps到SecDevOps

不光要快，還要安全。無論是真正的高鐵，還是DevOps。對于中小企業來說，安全就是生命線，誰也不敢在資產安全問題上掉以輕心。

針對中小企業來說，要完整地構建安全編碼的能力，缺少這樣的實踐，同時，也缺少比較好的規則引擎。我們采用代碼平臺內置的代碼規約掃描把一般的編程中容易導致安全漏洞的代碼給識別出來，同時，我們也通過一些敏感信息掃描，來識別是否有把安全相應的信息給明文化出來。

同時，針對工具平臺本身的安全，同樣采用代碼平臺提供的白名單設置，權限管理等，來提前做好安全的防控，做到事前預防；同時，在過程，工具平臺，還可以對一些異常行為（如批量的代碼轉移或刪除動作）進行監控，提前提出預警，做到事中監控；一旦發現問題，我們也可以利用平臺的日志功能，來做到事后追溯的目的。

整體上來說，這些安全的能力已經完全夠用，如果不想用到這些能力，想用自己的話，也可以，disable掉，接入自己的就可以了。不過，我還是建議那些沒有太多安全防控能力的企業，直接采用平臺內置的功能，省得重復制造輪子。

寫在后面

問題永遠是創新發展的發動機。在商米走向DevOps的路上，正是這樣一個個的問題，促使著我們去探索發現，也正是這樣每一次的探索發現，在解決問題路上的那點小糾結、小成就、小雀喜，讓我們在解決問題的路上走得更堅定，更有信心。

感謝在我們成長路上幫助過的人們，正是你們的毫無保留地幫助，才讓我們走得越來越有信心。我們依舊在路上。

希望我們的故事，能夠對你有一點點啟發，哪怕只是一點點，我們也會很開心。

作者介紹

文振熙，2015年加入SUNMI科技，一直從事云計算研發管理相應崗位，當前任職「SUNMI-云計算委員會主任」、「SUNMI-SBS業務線后端委員會組長」。曾推動SUNMI多次轉型：Go語言推廣、全面SOA服務化、K8s容器化落地、Wayne自助平臺以及云效CI/CD落地等。

開源作品：

• CSDN認證專家

• PhalApi PHP-API開源框架核心開發者

• sunmi-OS/gocore &wenzhenxi/gorsa 開源項目作者

劉文灃，2017年加入SUNMI科技，從業務開發至前端研發管理，現任職「SUNMI-SBS業務線前端委員會組長」。先后承擔多次技術攻堅及推動技術演進：ng1向React棧的遷移改造、基于Webrtc的設備遠控功能、前端自動化構建及容器化部署、項目微應用化以及云效CI/CD落地等。