作為一名研發人員，你的工作中有沒有遇到類似的問題：分支如何管理才能更好地提升研發和CI效率？單元測試如何做才能更高效？代碼評審要不要做，審什么？想上容器，有哪些好的實踐可以借鑒？好的策略可以使開發工作事半功倍，讓軟件交付提質增效。
本文由資深DevOps咨詢顧問段亞浩，來為大家詳解如何通過對分支策略、代碼質量/規范、云原生支持等多個方面的加強和優化，讓開發人員提升研發效能。
段亞浩老師說道，研發端需要注意的事項不少，例如規范和規則等。本文我們先分享分支策略、單元測試、代碼質量檢查、代碼評審、容器化策略這幾個方面，后續有機會的話老師會再給大家分享其他的策略。通過這些策略，希望能加快交付的速度，同時保證產品的質量。
01. 分支策略
1）代碼管理工具：SVN or Git
大家用的比較多的代碼管理工具有SVN和Git，Git是業界主流的代碼管理工具。Git的優勢有很多，比如在分支管理這塊靈活快速、與Linux和Docker一脈相承等。由于同是Linus的代表作品，Git和Linux在文件管理方面有很多類似的地方。又如現在很火的云原生，未來你如果需要用到容器Docker，Git和Docker的命令也很相似，使用起來學習成本較低。不僅如此，將來如果要打通DevOps工具鏈的話，使用Gitlab也更加方便些。
2）為什么要使用分支
既然說的是分支策略，那么接下來就談談在什么場景下，需要用到分支。我們來設想下面幾種情況：
- 我們在基于一個穩定的版本在進行開發，突然在穩定版本上有一個緊急的bug需要我們解決。
- 我們在軟件中加入了一個小的特性，但是開發到一半的時候，發現開發組的另一個的想法更有創意，所以我們想廢棄自己的更改。
- 團隊想在軟件中同時加入多個特性，但是希望并行開發，而不是依次開發。
針對以上幾種典型場景，就建議我們使用分支來處理：
- 如果穩定版本有一個緊急bug需要處理，那么我們就可以基于穩定版本分支創建一個新分支，切換到該分支并修改bug，經過測試、發布之后，我們將該分支合并到穩定分支即可。
- 假設我們想廢棄正在開發的某個特性，如果該特性在一個單獨的分支上，只需要簡單的刪除該分支即可。
- 如果我們想并行開發多個特性，我們可以創建多個分支，分別開發，然后將每個分支都合并到穩定分支上即可。
3）分支管理模式分類
分支管理模式主要分為兩種類型：基于主干開發的Trunk Based Development（TBD）和基于分支開發的Feature Branching。
TBD（主干開發模式）的優勢是所有最新代碼都在主干上。缺點也很明顯，由于所有代碼都在主干上，發布的時候若沒有遵循規則，則容易出現問題。尤其是多版本并行開發的時候，可能會出現不是這個版本的代碼也被提交到主干上來了。當然，也有方法可以減少類似錯誤的發生：比如使用特性開關、或者做相應的規范約束，即約定好不在目前發布版本里的功能就盡量不要在目前的時間段內進行提交。不過這樣可能會對開發進度有所影響。TBD的關鍵點為：
- 同一個產品開發的所有人員共享一個Repository，有一個共同的trunk。單一Developer或是Developer團隊可以有自己的private branch，所有修改最后都會回到主干。
- 只有在Release時才會有官方的分支，一般Developer不能對Release Branch做動作，只有Release Engineer可以更動Release Branch，當Release Branch完成它的任務，就會被砍掉。
- Bug先在trunk修好，之后把Commit合并到Release Branch，而不是在Release Branch修好再整合到trunk，這樣可以把修改Release Branch的人限制在最小程度。
分支開發模式的代表是GitFlow。GitFlow模型是若干分支開發模式的集大成者，包含一個主干分支、一個開發分支、許多的特性分支、許多的發布分支和 Hotfix 分支，以及許多繁瑣的合并規則。由于對每個階段的每項操作定義十分明確，它曾經是很多重視流程的企業眼里的香饃饃。但它使用起來并不容易，大量的合并沖突和對集成測試不友好也是它被詬病最多的地方。
GitFlow分支模型里有兩個常駐分支：develop分支和master分支。所有的開發過程是基于develop去拉特性分支（feature branches），然后開發人員再在特性分支上進行開發，開發完成自測后再合并到develop分支上。此時，develop就相當于一個集成分支，集合所有最新的代碼。在某一個時間節點，基于develop分支再拉出一個發布分支（release branches），并在測試環境下做測試，測試通過的代碼會同時合到master和develop分支上，并在master分支上打一個標簽tag。（如下圖）在生產環境下，如果出現故障，就基于該版本的tag拉出一個hotfixes分支進行修復。
02. 單元測試
根據以往咨詢項目時的經驗來看，很多公司都是不做單元測試或者很少做單元測試的，因為覺得單元測試代碼編碼工作量大、投入高，短時間內難以滿足單測覆蓋率要求，且投入產出比不高。但單元測試是研發階段保障代碼功能的有效手段，如果缺了單元測試，后期接口測試和系統集成測試階段問題會很多，造成研發和測試反復多次交接，反而對交付速度更不利。所以還是建議將質量左移，在前期投入更多時間和精力來做單元測試，其實它的投入產出比是更高的。建議大家可以引入一些自動化工具進行協助：
分享三個自動代碼生成工具，所依賴的環境、支持語言等詳見下圖，推薦嘗試一下EvoSuite：
03. 代碼質量檢查
SonarQube是一款大眾較為熟悉的代碼檢查軟件。SonarQube可以集成一些常用的工具比如PMD、Checkstyle、findbugs、阿里p3c。待工具都準備好以后，由架構師評審篩選代碼規則，確定形成組織級的代碼掃描規范規則集。
盡管Sonar被大家所熟知，但其在21年第4季度時爆出漏洞，以及國家對金融行業使用開源軟件的管理要求，已經有企業在考慮國產化軟件。除此之外，信創適配在近幾年也是國家政策所號召的方向。在此，我們介紹一款在藍鯨DevOps平臺中的代碼掃描工具CodeCC，它是基于騰訊多年沉淀的代碼掃描規則所打造。CodeCC是通過靜態代碼分析，找出代碼隱藏的錯誤和缺陷，幫助開發人員快速解決質量問題和安全漏洞，助力交付高質量。所具備的優勢諸如：
語言：提供支持主流語言代碼掃描的多種掃描插件；
趨勢：統計代碼掃描、歷史趨勢比較；
建議：提供告警詳情及錯誤代碼位置，規范化的修復指導，降低修復成本；
效率：支持增量掃描，縮短掃描的時間；
…..
掃描出代碼問題僅僅是第一步。如果能夠把掃描和流水線結合起來，即當問題超過某一個標準或閾值流水線就會自動中斷，便能讓質量保證自動化。因此，可以把這些標準定義成紅線規則，通過藍鯨DevOps平臺，與流水線結合，確保交付物的準出。
04. 代碼評審
可能很多人會問，代碼質量提高以后，代碼評審還有必要嗎？當然是有的！很多公司不搞評審的常見原因有：需求變化太快、項目時間緊張、領導更關注業務交付，不太明白代碼評審的意義等。
但我們認為，這些都沒辦法抵消代碼評審的重要性，因為心思再慎密的人也有疏漏的時候，代碼多review可以避免一些問題。并且，代碼評審對代碼的結構調整很有好處。如果一個reviewer看不懂你寫的代碼，那就不要指望當你離開后有多少人可以看懂了，維護成本會更大。第三，代碼評審還可以促進團隊之間相互交流，不會因為別人不在做這一塊就不知道這些代碼的作用。再小的團隊都有必要做審查，除非這個團隊就只有一個人。
其實，大可不必對代碼評審過于煩惱。因為代碼規范檢查工具可以很輕松的完成大部分機械的檢查工作，剩下需要人工做的僅僅是評審代碼設計及可維護性，比如：
- 代碼邏輯間是否足夠的解耦
- 復雜邏輯是否有明確的注釋
- 可能出異常的邏輯是否有異常處理
藍鯨DevOps平臺已經把代碼檢查單進行了線上化，在進行代碼評審時，可根據檢查單勾選所需檢查項即可。想了解更多平臺的功能，歡迎掃描文末二維碼進行咨詢試用。
05. 容器化策略
現在容器的引入也越來越多，因為容器的優勢很明顯：能夠解決環境不一致的問題。其他的優勢還包括使得持續交付和部署更方便、讓啟動時間更加快速、資源利用更高效等等。
1）容器最佳實踐一：
Dockerfile容器化的七大原則：不要在容器中存儲數據、不要發布兩份應用、清除不必要的包和文件、不要在容器中運行多個進程、不要在鏡像中存儲憑據，使用環境變量、使用非root用戶運行、不要依賴IP地址。
在鏡像這塊，我們希望它盡量的小。預期諸如能夠快速構建鏡像、更快拉取鏡像、解決存儲空間。具體的做法：使用微鏡像、減小鏡像層數、避免不必要包安裝、復用Cache、使用Volume、清理yum/apk cache。
2）容器最佳實踐二：容器應用
容器在運行時，同樣也需要注意幾個問題：
① 鏡像要盡可能的小
通過清理臨時文件，并避免安裝不必要的軟件包來構建小尺寸鏡像。這樣能夠減少容器的尺寸，構建時間和復制容器鏡像的網絡傳輸時間。
② 支持任意用戶ID
避免使用sudo命令或要求特定用戶名運行你的容器。
③ 標記重要的端口
雖然可以在運行時指定端口號，然而通過使用EXPOSE命令在運行的時候指定，則可以讓鏡像的使用者更輕松。
④ 為持久數據使用卷
對容器摧毀之后還需要保存的容器數據的情況，必須將數據寫入一個數據卷。
⑤ 設置鏡像元數據
以標簽和注釋形式存在的鏡像元數據可以使您的容器鏡像更加實用，從而為使用您容器的開發人員提供了更好的體驗。
⑥ 使主機和鏡像同步
一些容器應用需要容器在某些屬性（如時間和機器ID）上與主機同步。
有了上述的實踐，相信大家對容器也有了更多的見解。對想要進行容器化改造的企業，在這里我們也分享一下具體的改造步驟，可供參考實踐：
- 建設組織級鏡像倉庫（若有Artifactory，可使用其作為Docker鏡像倉庫；如果沒有，建議選用Harbor作為鏡像倉庫）。
- 制定鏡像管理規范，確定是由哪個部門來管。
- 關于基礎鏡像、中間件鏡像構建、管理及維護，要有專人負責。
- 制定不同語言類型的標準鏡像模板及CICD工作流。
- 結合鏡像管理規范對現有應用進行容器化改造（如一些目錄調整、啟停腳本編寫等）。
- 選擇合適應用進行試點。
- 試點階段回顧與總結，持續反饋、持續改進。
- 制定全面推廣策略并實施。
有了方法論，我們還需要親自實踐才能落地到實處，并在逐步實踐的過程中進行迭代優化，形成最適合自己企業的研發策略。這個過程可能并不是那么容易，但是萬事開頭難，善用科技和工具解決一些重復性和人工易出錯的問題，才能把人的時間和力量花在更有價值的地方。
