背景
從軟件開發到正式上線一般經過開發、測試、上線三個大流程，但是每個流程都應該有一定的流程規范機制。沒有規范，很容易導致線上事故。此外，也易導致維護難，代碼可讀性差等問題。針對研發方面主要可能存在以下幾個方面的規范，注意規范不是不變的下面的部分規范是個人目前認為比較合理的一種實踐方案，歡迎提出建議，探尋更加合理的方案。
開發
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.質量規范
在線上出現問題后，在出現的問題解決后，需要對問題進行一個總結報告。包含問題產生的原因以及處理方法進行總結記錄。