設定好DevOps轉型下的研發策略,提升開發人員的研發效能

語言: CN / TW / HK

原文出自:嘉為藍鯨服務號  資料下載:點這裡

作為一名研發人員,你的工作中有沒有遇到類似的問題:分支如何管理才能更好地提升研發和CI效率?單元測試如何做才能更高效?程式碼評審要不要做,審什麼?想上容器,有哪些好的實踐可以借鑑?好的策略可以使開發工作事半功倍,讓軟體交付提質增效。

本次直播我們邀請到資深DevOps諮詢顧問段亞浩,來為大家詳解如何通過對分支策略、程式碼質量/規範、雲原生支援等多個方面的加強和優化,讓開發人員提升研發效能。

精彩回顧一睹為快:DevOps研發端策略如何設定?

段亞浩老師說道,研發端需要注意的事項不少,例如規範和規則等。本次直播,我們先分享分支策略、單元測試、程式碼質量檢查、程式碼評審、容器化策略這幾個方面,後續有機會的話老師會再給大家分享其他的策略。通過這些策略,希望能加快交付的速度,同時保證產品的質量。

更多DevOps深度文章請戳:

1.為什麼精益與DevOps相得益彰?

2.企業該如何解決DevOps轉型道路上的常見障礙?

3.DevOps方法論掌握這四點,實踐出真知

 

一、分支策略

1.程式碼管理工具:SVN or Git

大家用的比較多的程式碼管理工具有SVN和Git,Git是業界主流的程式碼管理工具。Git的優勢有很多,比如在分支管理這塊靈活快速、與Linux和Docker一脈相承等。由於同是Linus的代表作品,Git和Linux在檔案管理方面有很多類似的地方。又如現在很火的雲原生,未來你如果需要用到容器Docker,Git和Docker的命令也很相似,使用起來學習成本較低。不僅如此,將來如果要打通DevOps工具鏈的話,使用Gitlab也更加方便些。

設定好DevOps轉型下的研發策略,提升開發人員的研發效能

▲ SVN vs Git

點選檢視:常見的程式碼靜態檢查關注點

 

2.為什麼要使用分支

既然說的是分支策略,那麼接下來就談談在什麼場景下,需要用到分支。我們來設想下面幾種情況:

  • 我們在基於一個穩定的版本在進行開發,突然在穩定版本上有一個緊急的bug需要我們解決。
  • 我們在軟體中加入了一個小的特性,但是開發到一半的時候,發現開發組的另一個的想法更有創意,所以我們想廢棄自己的更改。
  • 團隊想在軟體中同時加入多個特性,但是希望並行開發,而不是依次開發。

針對以上幾種典型場景,就建議我們使用分支來處理:

  • 如果穩定版本有一個緊急bug需要處理,那麼我們就可以基於穩定版本分支建立一個新分支,切換到該分支並修改bug,經過測試、釋出之後,我們將該分支合併到穩定分支即可。
  • 假設我們想廢棄正在開發的某個特性,如果該特性在一個單獨的分支上,只需要簡單的刪除該分支即可。
  • 如果我們想並行開發多個特性,我們可以建立多個分支,分別開發,然後將每個分支都合併到穩定分支上即可。

 

關於Git分支的理解和互動式學習Git分支,可點選下載資料

 

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的人限制在最小程度。

設定好DevOps轉型下的研發策略,提升開發人員的研發效能

▲ TBD模型圖(圖片來源網路,如有侵權請聯絡刪除)

分支開發模式的代表是GitFlow。GitFlow模型是若干分支開發模式的集大成者,包含一個主幹分支、一個開發分支、許多的特性分支、許多的釋出分支和 Hotfix 分支,以及許多繁瑣的合併規則。由於對每個階段的每項操作定義十分明確,它曾經是很多重視流程的企業眼裡的香饃饃。但它使用起來並不容易,大量的合併衝突和對整合測試不友好也是它被詬病最多的地方。

GitFlow分支模型裡有兩個常駐分支:develop分支和master分支。所有的開發過程是基於develop去拉特性分支(feature branches),然後開發人員再在特性分支上進行開發,開發完成自測後再合併到develop分支上。此時,develop就相當於一個整合分支,集合所有最新的程式碼。在某一個時間節點,基於develop分支再拉出一個釋出分支(release branches),並在測試環境下做測試,測試通過的程式碼會同時合到master和develop分支上,並在master分支上打一個標籤tag。(如下圖)在生產環境下,如果出現故障,就基於該版本的tag拉出一個hotfixes分支進行修復。

設定好DevOps轉型下的研發策略,提升開發人員的研發效能

▲ GitFlow分支模型圖(圖片來源網路,如有侵權請聯絡刪除)

關於不同分支策略分析、優缺點和適用場景,在幻燈片第12張,點選下載

 

二、單元測試

根據以往諮詢專案時的經驗來看,很多公司都是不做單元測試或者很少做單元測試的,因為覺得單元測試程式碼編碼工作量大、投入高,短時間內難以滿足單測覆蓋率要求,且投入產出比不高。但單元測試是研發階段保障程式碼功能的有效手段,如果缺了單元測試,後期介面測試和系統整合測試階段問題會很多,造成研發和測試反覆多次交接,反而對交付速度更不利。所以還是建議將質量左移,在前期投入更多時間和精力來做單元測試,其實它的投入產出比是更高的。建議大家可以引入一些自動化工具進行協助:

設定好DevOps轉型下的研發策略,提升開發人員的研發效能

 

分享三個自動程式碼生成工具,所依賴的環境、支援語言等詳見下圖,推薦嘗試一下EvoSuite:

設定好DevOps轉型下的研發策略,提升開發人員的研發效能

 

點選檢視:微服務架構下的契約測試和Mock測試

 

三、程式碼質量檢查

SonarQube是一款大眾較為熟悉的程式碼檢查軟體。SonarQube可以整合一些常用的工具比如PMD、Checkstyle、findbugs、阿里p3c。待工具都準備好以後,由架構師評審篩選程式碼規則,確定形成組織級的程式碼掃描規範規則集。

儘管Sonar被大家所熟知,但其在21年第4季度時爆出漏洞,以及國家對金融行業使用開源軟體的管理要求,已經有企業在考慮國產化軟體。除此之外,信創適配在近幾年也是國家政策所號召的方向。在此,我們介紹一款在藍鯨DevOps平臺中的程式碼掃描工具CodeCC,它是基於騰訊多年沉澱的程式碼掃描規則所打造。CodeCC是通過靜態程式碼分析,找出程式碼隱藏的錯誤和缺陷,幫助開發人員快速解決質量問題和安全漏洞,助力交付高質量。所具備的優勢諸如:

語言:提供支援主流語言程式碼掃描的多種掃描外掛;

趨勢:統計程式碼掃描、歷史趨勢比較;

建議:提供告警詳情及錯誤程式碼位置,規範化的修復指導,降低修復成本;

效率:支援增量掃描,縮短掃描的時間;

…..

詳情可點選申請試用

 

掃描出程式碼問題僅僅是第一步。如果能夠把掃描和流水線結合起來,即當問題超過某一個標準或閾值流水線就會自動中斷,便能讓質量保證自動化。因此,可以把這些標準定義成紅線規則,通過藍鯨DevOps平臺,與流水線結合,確保交付物的準出。

設定好DevOps轉型下的研發策略,提升開發人員的研發效能

產品功能展示

設定好DevOps轉型下的研發策略,提升開發人員的研發效能

質量紅線場景分享

四、程式碼評審

可能很多人會問,程式碼質量提高以後,程式碼評審還有必要嗎?當然是有的!很多公司不搞評審的常見原因有:需求變化太快、專案時間緊張、領導更關注業務交付,不太明白程式碼評審的意義等。

但我們認為,這些都沒辦法抵消程式碼評審的重要性,因為心思再慎密的人也有疏漏的時候,程式碼多review可以避免一些問題。並且,程式碼評審對程式碼的結構調整很有好處。如果一個reviewer看不懂你寫的程式碼,那就不要指望當你離開後有多少人可以看懂了,維護成本會更大。第三,程式碼評審還可以促進團隊之間相互交流,不會因為別人不在做這一塊就不知道這些程式碼的作用。再小的團隊都有必要做審查,除非這個團隊就只有一個人。

其實,大可不必對程式碼評審過於煩惱。因為程式碼規範檢查工具可以很輕鬆的完成大部分機械的檢查工作,剩下需要人工做的僅僅是評審程式碼設計及可維護性,比如:

  • 程式碼邏輯間是否足夠的解耦
  • 複雜邏輯是否有明確的註釋
  • 可能出異常的邏輯是否有異常處理

藍鯨DevOps平臺已經把程式碼檢查單進行了線上化,在進行程式碼評審時,可根據檢查單勾選所需檢查項即可。

設定好DevOps轉型下的研發策略,提升開發人員的研發效能

▲ 程式碼檢查介面展示

五、容器化策略

現在容器的引入也越來越多,因為容器的優勢很明顯:能夠解決環境不一致的問題。其他的優勢還包括使得持續交付和部署更方便、讓啟動時間更加快速、資源利用更高效等等。

設定好DevOps轉型下的研發策略,提升開發人員的研發效能

 

容器化的七大原則:不要在容器中儲存資料、不要釋出兩份應用、清除不必要的包和檔案、不要在容器中執行多個程序、不要在映象中儲存憑據,使用環境變數、使用非root使用者執行、不要依賴IP地址。更加詳細的原則解釋,可點選下載

1.容器最佳實踐一:Dockerfile

在映象這塊,我們希望它儘量的小。預期諸如能夠快速構建映象、更快拉取映象、解決儲存空間。具體的做法:使用微映象、減小映象層數、避免不必要包安裝、複用Cache、使用Volume、清理yum/apk cache。

設定好DevOps轉型下的研發策略,提升開發人員的研發效能

 

2.容器最佳實踐二:容器應用

容器在執行時,同樣也需要注意幾個問題:

  • 映象要儘可能的小

通過清理臨時檔案,並避免安裝不必要的軟體包來構建小尺寸映象。這樣能夠減少容器的尺寸,構建時間和複製容器映象的網路傳輸時間。

  • 支援任意使用者ID

避免使用sudo命令或要求特定使用者名稱執行你的容器。

  • 標記重要的埠

雖然可以在執行時指定埠號,然而通過使用EXPOSE命令在執行的時候指定,則可以讓映象的使用者更輕鬆。

  • 為持久資料使用卷

對容器摧毀之後還需要儲存的容器資料的情況,必須將資料寫入一個數據卷。

  • 設定映象元資料

以標籤和註釋形式存在的映象元資料可以使您的容器映象更加實用,從而為使用您容器的開發人員提供了更好的體驗。

  • 使主機和映象同步

一些容器應用需要容器在某些屬性(如時間和機器ID)上與主機同步。

 

有了上述的實踐,相信大家對容器也有了更多的見解。對想要進行容器化改造的企業,在這裡我們也分享一下具體的改造步驟,可供參考實踐:

  1. 建設組織級映象倉庫(若有Artifactory,可使用其作為Docker映象倉庫;如果沒有,建議選用Harbor作為映象倉庫)。
  2. 制定映象管理規範,確定是由哪個部門來管。
  3. 關於基礎映象、中介軟體映象構建、管理及維護,要有專人負責。
  4. 制定不同語言型別的標準映象模板及CICD工作流。
  5. 結合映象管理規範對現有應用進行容器化改造(如一些目錄調整、啟停指令碼編寫等)。
  6. 選擇合適應用進行試點。
  7. 試點階段回顧與總結,持續反饋、持續改進。
  8. 制定全面推廣策略並實施。

 

關於容器雲平臺建設的方案分析,可點選下載資料

有了方法論,我們還需要親自實踐才能落地到實處,並在逐步實踐的過程中進行迭代優化,形成最適合自己企業的研發策略。這個過程可能並不是那麼容易,但是萬事開頭難,善用科技和工具解決一些重複性和人工易出錯的問題,才能把人的時間和力量花在更有價值的地方。