1 容器化規范

在應用的容器化改造規范中，需要考慮的主要因素有：容器的高可用性、容器的運維、容器的安全性、容器的多租戶隔離、容器的持久化存儲等，容器化的過程中需要符合以下規范和要求：
(一) 建立清晰的可自動化編譯和構建過程
使用Maven、Gradle、Make、Shell等工具實現編譯步驟自動化
(二) 實現應用配置參數的外部化
基于環境變量或者配置文件的配置管理，便于容器適配不同的運行環境
(三) 提供合理可靠的健康檢查接口
平臺將通過健康檢查判斷容器狀態，對應用服務進行狀態保持
(四) 實現應用狀態外部化，應用實例無狀態化
應用狀態信息存儲于數據庫或緩存等外部系統，實例實現無狀態化
(五) 不涉及底層操作系統依賴及復雜的網絡通訊機制
應用以處理業務為主，不強依賴于底層操作系統以及組播等網絡通信機制以提高可移植性
(六) 部署交付件及運行平臺的大小在2G以內
輕量級的應用便于在大規模集群中快速傳輸分發，更符合容器敏捷的理念
(七) 啟動時間在5min以內
過長的啟動時間不能發揮容器敏捷的特性

2 代碼管理規范

代碼管理我們使用git進行，git是一種較為先進的代碼版本管理及協同工作平臺，采用分布式文件塊存儲：
分布式：代碼保存在所有協同成員的計算機上，網速較差時依然可用；而傳統的集中式代碼版本管理系統則較難脫離網絡運行。
文件：直接以文件保存整個最新文檔，版本提交及恢復速度快：而傳統的增量式代碼版本管理系統則在每次提交及恢復時都需要對所有的增量進行求和，速度慢。

2.1 git常用概念

(一) 倉庫（Repositories）
類似我們生活中的倉庫，存儲東西，在這是網絡或者本地實際存放代碼的地方，同一個倉庫可存多個項目。
(二) 參照（References）
可以看做是指向文件塊中特定代碼版本的指針，可沿代碼版本有向圖進行向前（一般指提交操作Commit）,向后（一般是恢復操作Restore）, 跳轉（不同分支間的切換Switch）。
(三) 分支（Branch）
一般是為了進行代碼調試或概念開發，從主要的開發版本中分離出一個副版本，并在此基礎上進行修改，（實際中我們可以分離出來進行各自的模塊開發）使版本有向圖呈現分支狀態。
(四) 合并(Merge)
一般是為了將代碼調試或概念開發分支的代碼加入到主要版本中，將對兩部分的代碼進行比較：
先向后回朔兩個分支的最近公共節點，通過與最近的公共節點進行比較，分析兩個分支各對哪些文件進行了修改（因為是文件塊，所以需要對兩個版本的文件求差，傳統模式則需要對兩個版本的記錄進行求和）。
合并最容易產生的錯誤（沖突）如果某一個文件在 兩個版本中均被修改過，則視為“沖突”，這時我們解決的辦法是需要人工手動調整其中一個版本，需要確定找到兩次提交的相關人員，確定雙方修改的內容，進行邏輯的確認合并，切記此處不要隨便刪除改動一方的提交，一定要找到沖突雙方進行確認，否則會造成計劃外的錯誤和問題。
(五) 標簽（Tag）
不移動的參照，以標記特殊的代碼版本副本，比如說項目的里程碑等

2.2 git常用操作

(一) 新建分支
首先，每次開發新功能，都應該新建一個單獨的分支

# 獲取主干最新代碼 $ git checkout master $ git pull# 新建一個開發分支myfeature $ git checkout -b myfeature

(二) 提交分支commit
分支修改后，就可以提交commit了，建議，每天至少提交一次。

$ git add . $ git status $ git commit --verbose

git add 命令的all參數，表示保存所有變化（包括新建、修改和刪除）。從Git 2.0開始，all是 git add 的默認參數，所以也可以用 git add . 代替。
git status 命令，用來查看發生變動的文件。
git commit 命令的verbose參數，會列出 diff 的結果。

(三) 撰寫提交信息
提交commit時，必須給出完整扼要的提交信息，規范格式如下：

[Type]: subject Type包括： type用于說明 commit 的類別，只允許使用下面8個標識。 br: 此項特別針對bug號，用于向測試反饋bug列表的bug修改情況 feat：新功能（feature） fix：修補bug docs：文檔（documentation） style： 格式（不影響代碼運行的變動） refactor：重構（即不是新增功能，也不是修改bug的代碼變動） test：增加測試 chore：構建過程或輔助工具的變動 revert: feat(pencil): add 'graphiteWidth' option (撤銷之前的commit)

例：

[fix]: add 'graphiteWidth' option

(四) 與主干同步
分支的開發過程中，要經常與主干保持同步。

$ git fetch origin $ git rebase origin/master

(五) 合并commit
分支開發完成后，當本地留存大量commit，但是合并到主干的時候，往往希望只有一個（或最多兩三個）commit，這樣不僅清晰，也容易管理。可以使用git rebase 命令將多個commit合并。

$ git rebase -i origin/master

關于合并commit細節在此不進行贅述。

(六) 推送到遠程倉庫
合并commit后，需要推送當前分支到遠程倉庫

$ git push origin myfeature $ git push --force origin myfeature //rebase以后，分支歷史改變了，跟遠程分支不一定兼容，有可能要強行推送

(七) 發出Pull Request
提交到遠程倉庫以后，需要發出 Pull Request 到master分支，然后請求相關技術管理人員進行代碼review，確認后再合并到master。

2.3 其他

(一) 代碼庫分類：
a) 遠程倉庫：位于服務端，所有開發的代碼最終都要合到遠程倉庫。
b) 個人工作庫：位于每個開發人員的開發機器，從遠程倉庫（服務端）clone到本地。每個開發人員開發的代碼，先commit到個人工作庫，再由個人工作庫push到遠程倉庫的對應開發分支。

(二) 人員角色分類：
a) Owner：擁有遠程倉庫的所有權限。
b) Master：具有將開發人員的合并需求（MR）合入遠程倉庫主分支的權限。基于安全考慮，我們設置為只能通過MR的方式將代碼合入主分支，而不能直接push到主分支。
c) Developer：只能從自己的個人開發分支提交合并代碼的請求（MR），是否能夠合入主分支，由Master進行審核。

(三) 基本流程和分支管理基于git flow和github flow兩種流程模式
項目可以根據實際需求踐行對應的流程管理模式，具體的流程在2.3 分支管理規范中詳述。

3 分支管理規范

3.1 git-flow模型

git-flow 模式會預設兩個主分支在倉庫中，開發人員不可以直接操作這兩個分支，在開發完成的功能分支提交到遠程倉庫后，需要提出merge request，由技術管理人員審核后才能合并至develop分支。

(一) 發布主分支master：
a) 每個代碼庫有且僅有一個主分支 master。所有提供給用戶使用的正式版本，都在這個主分支上發布，同時都要一對一的生成一個 tag。除初始化倉庫生成的 master 分支以外，master 分支的所有提交都應是提供給用戶的正式版本。
b) master 分支僅用于發布正式版本，同時需確保主分支的任何內容都是可部署的。并且只允許對 master 進行其他分支的合并和創建標記操作，不能單獨在 master 分支上進行提交。
c) master 分支應該只授權給項目代碼的管理者，不允許其余人員操作。

(二) 開發主develop：
a) develop 分支是進行開發的基礎分支，其他的短特性分支是基于develop分支切分出來的，當你開始一個新的功能分支時，它將是開發的基礎。
b) 新功能的開發分支會合并在develop分支中，等待被整合到 master 分支中。

(三) master 分支應該只授權給項目代碼的管理者，不允許其余人員直接操作。

這兩個分支被稱作為長期分支。它們會存活在項目的整個生命周期中。而其他的分支，例如針對功能開發的分支，針對版本發布的分支，僅僅只是臨時存在的，它們是根據需要來創建的，當它們完成了自己的任務之后就會被刪除掉。

(四) 功能分支feature：
a) feature 分支為開發某個功能點而創建。
b) 完成功能點的開發后，feature 分支的最新內容會被部署至 staging 環境進行功能測試驗收。功能點測試完成后再合并入 develop分支，并刪除 feature 分支。
c) feature分支的名稱格式一般為feature-[任務號碼]的格式，例如feature-10980，10980對應任務管理平臺中的任務號碼。

(五) 預發布分支 release：
a) release 分支是指發布正式版本之前（即合并到 master 分支之前），基于develop分支切出來作為預發布版本以此進行測試的分支。一個 release 分支對應一個版本發布計劃，包含一個或多個的用戶故事、不定量的功能點、漏洞修復等。
b) 分支的命名格式為release-[版本號]，例如release-0.1.0。
c) 完成發布計劃的所有開發后，將 release 分支的內容部署到 UAT(User Acceptance Testing) 環境進行測試驗收，測試通過后，再將release分支合并入develop分支，并刪除該release分支，然后基于最新的develop分支創建一個新的版本標記。
d) 最后確認發布后，需要將develop分支合并至master分支，表示產品進行了發布，所有的新功能與新特性已經合并到了master分支。

(六) 修補Bug分支bugfix：
a) 修補 Bug 分支 bugfix 是指在開發過程中，對于發現的漏洞進行修補的分支，基于develop分支切分出來，與feature的開發過程比較類似。
b) 分支的命名格式為bugfix-[任務號碼]，例如bugfix-10980，10980對應任務管理系統中的bug任務號碼。
c) 完成漏洞修補的開發后，bugfix 分支的最新內容會被部署至 staging 環境進行功能測試驗收。最后將其合并入 develop分支，并刪除 bugfix 分支。

(七) 熱修復分支hotfix：
a) 軟件正式發布以后，難免會出現 Bug 。這時就需要創建一個 hotfix分支 ，進行 Bug 熱修復，與bugfix不同的地方在于，hotfix是基于master分支進行切分的，完成會合并入master分支，再合并到develop分支。
b) 分支的命名格式為hotfix-[新版本號碼]，例如hotfix-0.1.1。
c) 漏洞修復后需要為hotfix 分支制作一個新的修訂號版本標記。最后，根據實際情況可選的合并入 master 分支，再合并到develop分支，并刪除 hotfix 分支。

3.2 github-flow 模型

Github-flow分支模型與git-flow分支模型比較類似，區別在于github-flow模型中去除了develop分支，預設的保護分支僅留master分支，feature、bugfix、release直接基于master分支切出進行開發，開發完畢后經由merge request合并至master分支，版本發布時tag直接打在release分支上，而后合并至master分支。而線上的熱修復分支hotfix則基于版本tag進行切出，確定修復后在hotfix分支上打出對應的版本tag，然后合并到master分支。除了master分支，其他分支在完成對應的工作后都需要合并到master分支，然后刪除。實際的分支管理示意圖如下：

4 版本控制規范

在軟件管理的領域里存在著被稱作“依賴地獄”的死亡之谷，系統規模越大，加入的包越多，你就越有可能在未來的某一天發現自己已深陷絕望之中。
在依賴高的系統中發布新版本包可能很快會成為噩夢。如果依賴關系過高，可能面臨版本控制被鎖死的風險（必須對每一個依賴包改版才能完成某次升級）。而如果依賴關系過于松散，又將無法避免版本的混亂（假設兼容于未來的多個版本已超出了合理數量）。當你專案的進展因為版本依賴被鎖死或版本混亂變得不夠簡便和可靠，就意味著你正處于依賴地獄之中。
我們的版本控制規范采用業內較為統一認可的語義化管理規范，大體版本格式為：
主版本號.次版本號.修訂號
版本號遞增規則如下：

主版本號：當你做了不兼容的 API 修改， 次版本號：當你做了向下兼容的功能性新增， 修訂號：當你做了向下兼容的問題修正。

先行版本號及版本編譯元數據可以加到“主版本號.次版本號.修訂號”的后面，作為延伸。
詳細規范如下：
(一) 使用語義化版本控制的軟件必須定義公共 API。該 API 可以在代碼中被定義或出現于嚴謹的文件內。無論何種形式都應該力求精確且完整。
(二) 標準的版本號必須采用 X.Y.Z 的格式，其中 X、Y 和 Z 為非負的整數，且禁止在數字前方補零。X 是主版本號、Y 是次版本號、而 Z 為修訂號。每個元素必須以數值來遞增。例如：1.9.1 -> 1.10.0 -> 1.11.0。
(三) 標記版本號的軟件發行后，禁止改變該版本軟件的內容。任何修改都必須以新版本發行。
(四) 主版本號為零（0.y.z）的軟件處于開發初始階段，一切都可能隨時被改變。這樣的公共 API 不應該被視為穩定版。
(五) 的版本號用于界定公共 API 的形成。這一版本之后所有的版本號更新都基于公共 API 及其修改內容。
(六) 修訂號 Z（x.y.Z | x > 0）必須在只做了向下兼容的修正時才遞增。這里的修正指的是針對不正確結果而進行的內部修改。
(七) 次版本號 Y（x.Y.z | x > 0）必須在有向下兼容的新功能出現時遞增。在任何公共 API 的功能被標記為棄用時也必須遞增。也可以在內部程序有大量新功能或改進被加入時遞增，其中可以包括修訂級別的改變。每當次版本號遞增時，修訂號必須歸零。
(八) 主版本號 X（X.y.z | X > 0）必須在有任何不兼容的修改被加入公共 API 時遞增。其中可以包括次版本號及修訂級別的改變。每當主版本號遞增時，次版本號和修訂號必須歸零。
(九) 先行版本號可以被標注在修訂版之后，先加上一個連接號再加上一連串以句點分隔的標識符來修飾。標識符必須由 ASCII 字母數字和連接號 [0-9A-Za-z-] 組成，且禁止留白。數字型的標識符禁止在前方補零。先行版的優先級低于相關聯的標準版本。被標上先行版本號則表示這個版本并非穩定而且可能無法滿足預期的兼容性需求。范例：1.0.0-alpha、1.0.0-alpha.1、1.0.0-0.3.7、1.0.0-x.7.z.92。
(十) 版本編譯元數據可以被標注在修訂版或先行版本號之后，先加上一個加號再加上一連串以句點分隔的標識符來修飾。標識符必須由 ASCII 字母數字和連接號 [0-9A-Za-z-] 組成，且禁止留白。當判斷版本的優先層級時，版本編譯元數據可被忽略。因此當兩個版本只有在版本編譯元數據有差別時，屬于相同的優先層級。范例：1.0.0-alpha+001、1.0.0+20130313144700、1.0.0-beta+exp.sha.5114f85。
(十一) 版本的優先層級指的是不同版本在排序時如何比較。判斷優先層級時，必須把版本依序拆分為主版本號、次版本號、修訂號及先行版本號后進行比較（版本編譯元數據不在這份比較的列表中）。由左到右依序比較每個標識符，第一個差異值用來決定優先層級：主版本號、次版本號及修訂號以數值比較，例如：1.0.0 < 2.0.0 < 2.1.0 < 2.1.1。當主版本號、次版本號及修訂號都相同時，改以優先層級比較低的先行版本號決定。例如：1.0.0-alpha < 1.0.0。有相同主版本號、次版本號及修訂號的兩個先行版本號，其優先層級必須透過由左到右的每個被句點分隔的標識符來比較，直到找到一個差異值后決定：只有數字的標識符以數值高低比較，有字母或連接號時則逐字以 ASCII 的排序來比較。數字的標識符比非數字的標識符優先層級低。若開頭的標識符都相同時，欄位比較多的先行版本號優先層級比較高。范例：1.0.0-alpha < 1.0.0-alpha.1 < 1.0.0-alpha.beta < 1.0.0-beta < 1.0.0-beta.2 < 1.0.0-beta.11 < 1.0.0-rc.1 < 1.0.0。

5 環境管理規范

軟件開發環境(Software Development Environment，SDE)是指在基本硬件和宿主軟件的基礎上，為支持系統軟件和應用軟件的工程化開發和維護而使用的一組軟件，簡稱SDE。它由軟件工具和環境集成機制構成，前者用以支持軟件開發的相關過程、活動和任務，后者為工具集成和軟件的開發、維護及管理提供統一的支持。環境管理規范基于業內IT項目管理的基礎規范進行整理。軟件應用開發的經典模型有這樣幾個環境：開發環境(DEV)、集成環境(SIT)、測試環境(TEST)、QA驗證(QA)、用戶接受度測試環境(UAT)、類生產環境(PRE)、生產環境(PROD)。而根據實際項目管理經驗中，我們認為最少需要4個環境進行實際開發。

5.1 DEV環境

開發人員或者開發團隊的工作環境，可以根據開發的需求隨時將變更更新在環境當中用于測試，可以是開發人員的本地環境，也可以是團隊統一的環境，此環境必須與其他環境和資源嚴格隔離。

5.2 SIT環境

該環境用于測試所有開發人員的代碼進行整合之后運行環境，供測試人員使用。目前結合更為成熟的開發模式和DevOps工具，將該環境與DEV環境整合在一起，盡可能快的產生能夠運行測試的交付環境。

5.3 UAT環境

UAT環境主要是用來作為客戶體驗驗證測試的環境，供真實用戶驗收使用。UAT環境應盡可能多地模擬生產環境，也可以兼作演示、培訓用環境。

5.4 PROD環境

即正式環境，軟件經過層層測試校驗后會部署在正式給用戶使用的環境，該環境由于性能要求等可能會采用分布式、集群式等復雜的架構，部署生產環境是一件非常嚴肅的事情，需要避免一些可能出現的問題。
除以上環境之外，可根據項目管理的實際需求進行部分調整，例如自動化測試環境、壓力測試環境、預發布環境等，其他特例環境在此不做贅述，可根據實際需求做出對應調整。

總結

以上是生活随笔為你收集整理的软件开发管理规范的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。