背景
從軟體開發到正式上線一般經過開發、測試、上線三個大流程，但是每個流程都應該有一定的流程規範機制。沒有規範，很容易導致線上事故。此外，也易導致維護難，程式碼可讀性差等問題。針對研發方面主要可能存在以下幾個方面的規範，注意規範不是不變的下面的部分規範是個人目前認為比較合理的一種實踐方案，歡迎提出建議，探尋更加合理的方案。
開發
1.分支管理
現如今開發基本上是通過git等軟體進行程式碼庫管理和協作開發。而對於這種協作開發的模式，很重要的一個內容就是分支管理。分支管理如果不做好可能會出現需求上線日期衝突，通過規範的分支管理措施能有效解決這些問題。一種簡單的分支管理方法如下：
-
分支命名規範：需求類的分支和bug修復類的分支需要進行區分，比如需求分支命名新增字首feature，bug修復分支命名字首可用fix。QA測試分支可直接使用test，線上釋出版本字首可使用release加上該版本第一次釋出日期。
-
-
需求分支的源分支為master，bug修復分支的源分支為bug存在的release分支。
-
當需求分支和bug修復分支達到可交付QA進行測試驗證的情況下，將指定分支合併到QA測試的分支比如test，這是因為QA可能同時測多個需求，且要對場景進行迴歸測試。
-
當QA測試完畢後，從master或者最近上線的release分支拉出release分支作為釋出分支，一同上線的需求可以一起合併到該分支然後刪除源分支，bug修復分支亦如此。新發布的release分支需要新增該版本第一次釋出日期作為版本號即從release分支拉出分支並加上日期版本號，用以記錄釋出的程式碼庫，避免線上多個版本部署問題出現後，能夠通過執行的版本找到程式碼出現的問題。
-
當release線上釋出成功並驗證成功後，將其合併到master分支，作為後續需求的源分支，若出現問題則release分支為bug修復分支的源分支，注意每次分支合併需要解決版本衝突。
-
-
釋出規範：線上釋出的版本都是release分支並且記錄了第一次釋出的版本號，源分支為線上執行的最新分支，一般為master，當需求密集時可能是最近的release分支。若運維工具無回滾功能可根據對應釋出日期版本進行編譯回滾，從而實現簡單的回滾功能。
具體分支管理如圖所示：
2.程式碼風格及規範
良好的程式碼規範及限制可以有效的將整個團隊的程式碼風格統一從而提高程式碼的可維護性。一般來講，好的程式碼具有風格一致、註釋清晰、命名正確、圈複雜度低等特點。對於風格問題通過IDE比如Idea、Eclipse的風格配置檔案以及格式化可以有效將程式碼風格進行統一，此外通過checkStyle以及git的hook機制可以有效的限制不符合程式碼風格的提交。而針對一些常見的bug和複雜度通過sonar、pmd、findbugs等程式碼檢查工具也可以進行程式碼審查。程式碼風格及規範的流程機制的大概分為以下幾個過程
-
程式碼風格一致性檢查。主要包括程式碼縮排、無用包匯入、換行風格等等。此部分可由兩種實現一種是通過IDE的git提交外掛時對程式碼進行格式化，第二種則主要是通過Idea的Save Actions對程式碼自動儲存時將程式碼進行格式化。當然除了本地的格式化我們也應當通過一些強制校驗手段比如checkStyle，checkStyle能夠通過配置檔案的方式來約束程式碼風格，通過maven plugin方式整合可以在指定的maven生命週期對違約程式碼進行提示，亦可通過git的hook機制避免違約程式碼提交。具體
-
程式碼單測覆蓋率檢查。好的程式碼應針對核心邏輯具有完善的單測覆蓋，單測覆蓋主要關注的指標除了行覆蓋率外還應重點關注分支覆蓋率，避免多case情況下，部分case沒有被覆蓋到。此部分可以通過jacoco來對程式碼覆蓋率的情況生成報告，並約束覆蓋率達標指標。也可通過maven plugin的方式進行整合。
-
程式碼bug檢測。針對可能出現的bug比如equals空指標等問題，可以通過sonar等三方平臺進行檢測，也可以通過findbugs、pmd等maven外掛進行檢測。
-
Code Review。以上都是屬於自動流程機制，通過Jenkins等平臺進行流水線編排能夠很好的實現以上功能，除此之外我們不能少的是Code Review機制。在以上自動化流程通過後，codeReview將著重於命名、程式碼可讀性、SQL等無法通過自動化機制實現的方面進行Review，減少CR帶來的工作量。
上線
1.上線規範
在功能需求開發完成後，我們需要進行上線。對於上線一般有以下幾點。
-
針對上線內容的變更通過VMS或者ChangeLog的方式記錄本次上線的內容。具體包含配置檔案變更、程式碼內容變更，可以通過git diff等對比軟體生成差異報告。針對變更的內容無論是ChangeLog還是做VMS都要做到Double Check，當然一般情況下通過VMS可能會更加方便，即內容更改以及審批都可以迅速體現，這也是基礎設施完善的一大優勢。
-
上線審批，針對VMS或ChangeLog已經內部進行Double Check的上線進行審批，即更高許可權的leader進行層級審批，避免上線隨意的情況。
2.質量規範
線上上出現問題後，在出現的問題解決後，需要對問題進行一個總結報告。包含問題產生的原因以及處理方法進行總結記錄。