研發流程優化實踐
- 2020 年 2 月 26 日
- 筆記
接下來會以 提高用戶價值的流動效率 為核心，列出一些具體的研發流程優化實踐
程式碼入庫前
程式碼入庫之前的開發活動，主要包括編碼、調測調優、靜態檢查、自動化測試、程式碼審查等。這是開發者編寫程式碼的步驟，自然是提高研發效能的關鍵環節。
程式碼集成越晚發現問題就越晚。這正是產品上線的最後關頭合併混亂，產品品質差、返工率高的一個重要原因。
規範化、自動化核心步驟
- 獲取開發環境，包括獲取開發機器、配置環境、獲取程式碼等。
- 在本地開發機器上進行開發，包括本地的編碼、調測、單元測試等。
- 程式碼入庫前，把改動提交到檢查中心（比如 Gerrit），再進行一輪系統檢查，主要包括程式碼檢查、單元測試、程式碼審查等，通過之後再入庫。
對應的有三個實踐：
- 提高開發環境的獲取效率。把整個開發環境的獲取，進行服務化、自助化。
- 規範化、自動化化本地檢查。根據團隊實際情況，找到合適的工具和配置進行這些檢查，並讓團隊成員統一使用。
- 建設自動化程式碼入庫前的檢查流程。比如merge request程式碼審查、使用 GitLab 提供的 GitLab CI/CD 框架自動化運行各種程式碼檢查工具
提供快速回饋，促進增量開發
提供快速回饋，進行增量開發指的是，能夠快速驗證已經完成的開發工作，說白了就是邊開發邊驗證。
- 靈活使用各種 Linter 和測試。最常用的快速驗證方法就是，提高運行靜態檢查和測試的方便性、靈活性。各種語言、框架都有自己的測試框架和 Linter，根據語言自行設置
- 使用實時檢驗工具。最常見的是，IDE 中的實時語法檢查。我們可以花一些時間來配置 IDE。另外，有些工具可以自動監視文件系統的變化，文件有變化時自動重啟服務。這對於開發者來說，非常便利。
程式碼入庫到產品上線
三個持續
持續集成：在團隊協作中，一天內多次將所有開發人員的程式碼合併入同一條主幹，推薦Trunk Based主幹分支模型
- 它能夠幫助開發人員盡量早、盡量頻繁地把自己的改動推送到共享的程式碼倉庫分支上，進行程式碼集成，從而減少大量程式碼衝突造成的低效能問題
- 更快地服務客戶，以更快的試錯速度尋找到用戶，提供真正對客戶有價值的功能
- 產品發布到不同環境的過程中，我們會提前發現一些在開發和持續集成中沒有暴露的問題
問題：如果有跨多個發布周期開發的功能，有兩種處理方式，一是功能開關，但會引進更多邏輯，二是放棄持續集成，那就需要開一個新的功能分支開發（功能分支模型）。所以團隊中使用哪種分支模型需要按下圖進行判斷：
持續交付：一種軟體工程方法，在短周期內完成軟體產品，以保證軟體保持在隨時可以發布的狀態
目標是，對每一個進入主幹分支的程式碼提交，構建打包成為可以發布的產品。對每一個提交，把集成後的程式碼部署到「類生產環境」中進行驗證。如果程式碼沒有問題，後續可以手動部署到生產環境中。
持續部署：將每一個程式碼提交，都構建出產品直接部署給用戶使用
值得一提的是，跟持續交付一樣，Facebook 的持續部署也不是純粹的持續部署。因為程式碼提交太多，他們並沒有每個提交都單獨部署，而是採用類似持續交付的方法，把一段時間之內的提交一起部署。這種不教條的方式，是 Facebook 到的一個重要的做事方法
三個原則
基本原則 1：流水線的測試要盡量完整
CI/CD 流水線的測試只有盡量完整，程式碼和產品的品質才能有保證。所以，最主要的工程實踐，就是在流水線中運行大量高品質的測試和檢查。
基本原則 2：流水線的運行速度一定要快
- 使用並行方式運行各種測試來提速
- 投入硬體資源，使用水平擴展的方式來提速
- 使用增量測試的方式進行精準驗證。也就是說，只運行跟當前改動最相關的測試，以減少測試用例的運行數量
- 讓開發人員在本地也能運行這些測試，從而使用本地資源儘早發現問題
- 運行測試的時候，按照一定的順序運行測試用例。比如可以先運行速度快的用例，以及歷史上容易發現問題的用例
基本原則 3：流水線使用的環境，盡量和生產環境一致
- 軟體包最好只構建一次，保證各種不同環境都用同一個包
- 使用 Docker 鏡像的方式，把發布的產品以及環境都打包進去，實現環境的一致性
- 盡量使用乾淨的環境。比如，測試時，使用剛從鏡像產生的系統；又比如，使用藍綠部署，每次產生新的部署時，直接丟棄舊的環境。
