软件开发管理规范
1 容器化規(guī)范
在應(yīng)用的容器化改造規(guī)范中，需要考慮的主要因素有：容器的高可用性、容器的運維、容器的安全性、容器的多租戶隔離、容器的持久化存儲等，容器化的過程中需要符合以下規(guī)范和要求：
(一) 建立清晰的可自動化編譯和構(gòu)建過程
使用Maven、Gradle、Make、Shell等工具實現(xiàn)編譯步驟自動化
(二) 實現(xiàn)應(yīng)用配置參數(shù)的外部化
基于環(huán)境變量或者配置文件的配置管理，便于容器適配不同的運行環(huán)境
(三) 提供合理可靠的健康檢查接口
平臺將通過健康檢查判斷容器狀態(tài)，對應(yīng)用服務(wù)進(jìn)行狀態(tài)保持
(四) 實現(xiàn)應(yīng)用狀態(tài)外部化，應(yīng)用實例無狀態(tài)化
應(yīng)用狀態(tài)信息存儲于數(shù)據(jù)庫或緩存等外部系統(tǒng)，實例實現(xiàn)無狀態(tài)化
(五) 不涉及底層操作系統(tǒng)依賴及復(fù)雜的網(wǎng)絡(luò)通訊機(jī)制
應(yīng)用以處理業(yè)務(wù)為主，不強(qiáng)依賴于底層操作系統(tǒng)以及組播等網(wǎng)絡(luò)通信機(jī)制以提高可移植性
(六) 部署交付件及運行平臺的大小在2G以內(nèi)
輕量級的應(yīng)用便于在大規(guī)模集群中快速傳輸分發(fā)，更符合容器敏捷的理念
(七) 啟動時間在5min以內(nèi)
過長的啟動時間不能發(fā)揮容器敏捷的特性
2 代碼管理規(guī)范
代碼管理我們使用git進(jìn)行，git是一種較為先進(jìn)的代碼版本管理及協(xié)同工作平臺，采用分布式文件塊存儲：
分布式：代碼保存在所有協(xié)同成員的計算機(jī)上，網(wǎng)速較差時依然可用；而傳統(tǒng)的集中式代碼版本管理系統(tǒng)則較難脫離網(wǎng)絡(luò)運行。
文件：直接以文件保存整個最新文檔，版本提交及恢復(fù)速度快：而傳統(tǒng)的增量式代碼版本管理系統(tǒng)則在每次提交及恢復(fù)時都需要對所有的增量進(jìn)行求和，速度慢。
2.1 git常用概念
(一) 倉庫（Repositories）
類似我們生活中的倉庫，存儲東西，在這是網(wǎng)絡(luò)或者本地實際存放代碼的地方，同一個倉庫可存多個項目。
(二) 參照（References）
可以看做是指向文件塊中特定代碼版本的指針，可沿代碼版本有向圖進(jìn)行向前（一般指提交操作Commit）,向后（一般是恢復(fù)操作Restore）, 跳轉(zhuǎn)（不同分支間的切換Switch）。
(三) 分支（Branch）
一般是為了進(jìn)行代碼調(diào)試或概念開發(fā)，從主要的開發(fā)版本中分離出一個副版本，并在此基礎(chǔ)上進(jìn)行修改，（實際中我們可以分離出來進(jìn)行各自的模塊開發(fā)）使版本有向圖呈現(xiàn)分支狀態(tài)。
(四) 合并(Merge)
一般是為了將代碼調(diào)試或概念開發(fā)分支的代碼加入到主要版本中，將對兩部分的代碼進(jìn)行比較：
先向后回朔兩個分支的最近公共節(jié)點，通過與最近的公共節(jié)點進(jìn)行比較，分析兩個分支各對哪些文件進(jìn)行了修改（因為是文件塊，所以需要對兩個版本的文件求差，傳統(tǒng)模式則需要對兩個版本的記錄進(jìn)行求和）。
合并最容易產(chǎn)生的錯誤（沖突）如果某一個文件在 兩個版本中均被修改過，則視為“沖突”，這時我們解決的辦法是需要人工手動調(diào)整其中一個版本，需要確定找到兩次提交的相關(guān)人員，確定雙方修改的內(nèi)容，進(jìn)行邏輯的確認(rèn)合并，切記此處不要隨便刪除改動一方的提交，一定要找到?jīng)_突雙方進(jìn)行確認(rèn)，否則會造成計劃外的錯誤和問題。
(五) 標(biāo)簽（Tag）
不移動的參照，以標(biāo)記特殊的代碼版本副本，比如說項目的里程碑等
2.2 git常用操作
(一) 新建分支
首先，每次開發(fā)新功能，都應(yīng)該新建一個單獨的分支
(二) 提交分支commit
分支修改后，就可以提交commit了，建議，每天至少提交一次。
git add 命令的all參數(shù)，表示保存所有變化（包括新建、修改和刪除）。從Git 2.0開始，all是 git add 的默認(rèn)參數(shù)，所以也可以用 git add . 代替。
git status 命令，用來查看發(fā)生變動的文件。
git commit 命令的verbose參數(shù)，會列出 diff 的結(jié)果。
(三) 撰寫提交信息
提交commit時，必須給出完整扼要的提交信息，規(guī)范格式如下：
例：
[fix]: add 'graphiteWidth' option(四) 與主干同步
分支的開發(fā)過程中，要經(jīng)常與主干保持同步。
(五) 合并commit
分支開發(fā)完成后，當(dāng)本地留存大量commit，但是合并到主干的時候，往往希望只有一個（或最多兩三個）commit，這樣不僅清晰，也容易管理。可以使用git rebase 命令將多個commit合并。
關(guān)于合并commit細(xì)節(jié)在此不進(jìn)行贅述。
(六) 推送到遠(yuǎn)程倉庫
合并commit后，需要推送當(dāng)前分支到遠(yuǎn)程倉庫
(七) 發(fā)出Pull Request
提交到遠(yuǎn)程倉庫以后，需要發(fā)出 Pull Request 到master分支，然后請求相關(guān)技術(shù)管理人員進(jìn)行代碼review，確認(rèn)后再合并到master。
2.3 其他
(一) 代碼庫分類：
a) 遠(yuǎn)程倉庫：位于服務(wù)端，所有開發(fā)的代碼最終都要合到遠(yuǎn)程倉庫。
b) 個人工作庫：位于每個開發(fā)人員的開發(fā)機(jī)器，從遠(yuǎn)程倉庫（服務(wù)端）clone到本地。每個開發(fā)人員開發(fā)的代碼，先commit到個人工作庫，再由個人工作庫push到遠(yuǎn)程倉庫的對應(yīng)開發(fā)分支。
(二) 人員角色分類：
a) Owner：擁有遠(yuǎn)程倉庫的所有權(quán)限。
b) Master：具有將開發(fā)人員的合并需求（MR）合入遠(yuǎn)程倉庫主分支的權(quán)限。基于安全考慮，我們設(shè)置為只能通過MR的方式將代碼合入主分支，而不能直接push到主分支。
c) Developer：只能從自己的個人開發(fā)分支提交合并代碼的請求（MR），是否能夠合入主分支，由Master進(jìn)行審核。
(三) 基本流程和分支管理基于git flow和github flow兩種流程模式
項目可以根據(jù)實際需求踐行對應(yīng)的流程管理模式，具體的流程在2.3 分支管理規(guī)范中詳述。
3 分支管理規(guī)范
3.1 git-flow模型
git-flow 模式會預(yù)設(shè)兩個主分支在倉庫中，開發(fā)人員不可以直接操作這兩個分支，在開發(fā)完成的功能分支提交到遠(yuǎn)程倉庫后，需要提出merge request，由技術(shù)管理人員審核后才能合并至develop分支。
(一) 發(fā)布主分支master：
a) 每個代碼庫有且僅有一個主分支 master。所有提供給用戶使用的正式版本，都在這個主分支上發(fā)布，同時都要一對一的生成一個 tag。除初始化倉庫生成的 master 分支以外，master 分支的所有提交都應(yīng)是提供給用戶的正式版本。
b) master 分支僅用于發(fā)布正式版本，同時需確保主分支的任何內(nèi)容都是可部署的。并且只允許對 master 進(jìn)行其他分支的合并和創(chuàng)建標(biāo)記操作，不能單獨在 master 分支上進(jìn)行提交。
c) master 分支應(yīng)該只授權(quán)給項目代碼的管理者，不允許其余人員操作。
(二) 開發(fā)主develop：
a) develop 分支是進(jìn)行開發(fā)的基礎(chǔ)分支，其他的短特性分支是基于develop分支切分出來的，當(dāng)你開始一個新的功能分支時，它將是開發(fā)的基礎(chǔ)。
b) 新功能的開發(fā)分支會合并在develop分支中，等待被整合到 master 分支中。
(三) master 分支應(yīng)該只授權(quán)給項目代碼的管理者，不允許其余人員直接操作。
這兩個分支被稱作為長期分支。它們會存活在項目的整個生命周期中。而其他的分支，例如針對功能開發(fā)的分支，針對版本發(fā)布的分支，僅僅只是臨時存在的，它們是根據(jù)需要來創(chuàng)建的，當(dāng)它們完成了自己的任務(wù)之后就會被刪除掉。
(四) 功能分支feature：
a) feature 分支為開發(fā)某個功能點而創(chuàng)建。
b) 完成功能點的開發(fā)后，feature 分支的最新內(nèi)容會被部署至 staging 環(huán)境進(jìn)行功能測試驗收。功能點測試完成后再合并入 develop分支，并刪除 feature 分支。
c) feature分支的名稱格式一般為feature-[任務(wù)號碼]的格式，例如feature-10980，10980對應(yīng)任務(wù)管理平臺中的任務(wù)號碼。
(五) 預(yù)發(fā)布分支 release：
a) release 分支是指發(fā)布正式版本之前（即合并到 master 分支之前），基于develop分支切出來作為預(yù)發(fā)布版本以此進(jìn)行測試的分支。一個 release 分支對應(yīng)一個版本發(fā)布計劃，包含一個或多個的用戶故事、不定量的功能點、漏洞修復(fù)等。
b) 分支的命名格式為release-[版本號]，例如release-0.1.0。
c) 完成發(fā)布計劃的所有開發(fā)后，將 release 分支的內(nèi)容部署到 UAT(User Acceptance Testing) 環(huán)境進(jìn)行測試驗收，測試通過后，再將release分支合并入develop分支，并刪除該release分支，然后基于最新的develop分支創(chuàng)建一個新的版本標(biāo)記。
d) 最后確認(rèn)發(fā)布后，需要將develop分支合并至master分支，表示產(chǎn)品進(jìn)行了發(fā)布，所有的新功能與新特性已經(jīng)合并到了master分支。
(六) 修補(bǔ)Bug分支bugfix：
a) 修補(bǔ) Bug 分支 bugfix 是指在開發(fā)過程中，對于發(fā)現(xiàn)的漏洞進(jìn)行修補(bǔ)的分支，基于develop分支切分出來，與feature的開發(fā)過程比較類似。
b) 分支的命名格式為bugfix-[任務(wù)號碼]，例如bugfix-10980，10980對應(yīng)任務(wù)管理系統(tǒng)中的bug任務(wù)號碼。
c) 完成漏洞修補(bǔ)的開發(fā)后，bugfix 分支的最新內(nèi)容會被部署至 staging 環(huán)境進(jìn)行功能測試驗收。最后將其合并入 develop分支，并刪除 bugfix 分支。
(七) 熱修復(fù)分支hotfix：
a) 軟件正式發(fā)布以后，難免會出現(xiàn) Bug 。這時就需要創(chuàng)建一個 hotfix分支 ，進(jìn)行 Bug 熱修復(fù)，與bugfix不同的地方在于，hotfix是基于master分支進(jìn)行切分的，完成會合并入master分支，再合并到develop分支。
b) 分支的命名格式為hotfix-[新版本號碼]，例如hotfix-0.1.1。
c) 漏洞修復(fù)后需要為hotfix 分支制作一個新的修訂號版本標(biāo)記。最后，根據(jù)實際情況可選的合并入 master 分支，再合并到develop分支，并刪除 hotfix 分支。
3.2 github-flow 模型
Github-flow分支模型與git-flow分支模型比較類似，區(qū)別在于github-flow模型中去除了develop分支，預(yù)設(shè)的保護(hù)分支僅留master分支，feature、bugfix、release直接基于master分支切出進(jìn)行開發(fā)，開發(fā)完畢后經(jīng)由merge request合并至master分支，版本發(fā)布時tag直接打在release分支上，而后合并至master分支。而線上的熱修復(fù)分支hotfix則基于版本tag進(jìn)行切出，確定修復(fù)后在hotfix分支上打出對應(yīng)的版本tag，然后合并到master分支。除了master分支，其他分支在完成對應(yīng)的工作后都需要合并到master分支，然后刪除。實際的分支管理示意圖如下：
4 版本控制規(guī)范
在軟件管理的領(lǐng)域里存在著被稱作“依賴地獄”的死亡之谷，系統(tǒng)規(guī)模越大，加入的包越多，你就越有可能在未來的某一天發(fā)現(xiàn)自己已深陷絕望之中。
在依賴高的系統(tǒng)中發(fā)布新版本包可能很快會成為噩夢。如果依賴關(guān)系過高，可能面臨版本控制被鎖死的風(fēng)險（必須對每一個依賴包改版才能完成某次升級）。而如果依賴關(guān)系過于松散，又將無法避免版本的混亂（假設(shè)兼容于未來的多個版本已超出了合理數(shù)量）。當(dāng)你專案的進(jìn)展因為版本依賴被鎖死或版本混亂變得不夠簡便和可靠，就意味著你正處于依賴地獄之中。
我們的版本控制規(guī)范采用業(yè)內(nèi)較為統(tǒng)一認(rèn)可的語義化管理規(guī)范，大體版本格式為：
主版本號.次版本號.修訂號
版本號遞增規(guī)則如下：
先行版本號及版本編譯元數(shù)據(jù)可以加到“主版本號.次版本號.修訂號”的后面，作為延伸。
詳細(xì)規(guī)范如下：
(一) 使用語義化版本控制的軟件必須定義公共 API。該 API 可以在代碼中被定義或出現(xiàn)于嚴(yán)謹(jǐn)?shù)奈募?nèi)。無論何種形式都應(yīng)該力求精確且完整。
(二) 標(biāo)準(zhǔn)的版本號必須采用 X.Y.Z 的格式，其中 X、Y 和 Z 為非負(fù)的整數(shù)，且禁止在數(shù)字前方補(bǔ)零。X 是主版本號、Y 是次版本號、而 Z 為修訂號。每個元素必須以數(shù)值來遞增。例如：1.9.1 -> 1.10.0 -> 1.11.0。
(三) 標(biāo)記版本號的軟件發(fā)行后，禁止改變該版本軟件的內(nèi)容。任何修改都必須以新版本發(fā)行。
(四) 主版本號為零（0.y.z）的軟件處于開發(fā)初始階段，一切都可能隨時被改變。這樣的公共 API 不應(yīng)該被視為穩(wěn)定版。
(五) 的版本號用于界定公共 API 的形成。這一版本之后所有的版本號更新都基于公共 API 及其修改內(nèi)容。
(六) 修訂號 Z（x.y.Z | x > 0）必須在只做了向下兼容的修正時才遞增。這里的修正指的是針對不正確結(jié)果而進(jìn)行的內(nèi)部修改。
(七) 次版本號 Y（x.Y.z | x > 0）必須在有向下兼容的新功能出現(xiàn)時遞增。在任何公共 API 的功能被標(biāo)記為棄用時也必須遞增。也可以在內(nèi)部程序有大量新功能或改進(jìn)被加入時遞增，其中可以包括修訂級別的改變。每當(dāng)次版本號遞增時，修訂號必須歸零。
(八) 主版本號 X（X.y.z | X > 0）必須在有任何不兼容的修改被加入公共 API 時遞增。其中可以包括次版本號及修訂級別的改變。每當(dāng)主版本號遞增時，次版本號和修訂號必須歸零。
(九) 先行版本號可以被標(biāo)注在修訂版之后，先加上一個連接號再加上一連串以句點分隔的標(biāo)識符來修飾。標(biāo)識符必須由 ASCII 字母數(shù)字和連接號 [0-9A-Za-z-] 組成，且禁止留白。數(shù)字型的標(biāo)識符禁止在前方補(bǔ)零。先行版的優(yōu)先級低于相關(guān)聯(lián)的標(biāo)準(zhǔn)版本。被標(biāo)上先行版本號則表示這個版本并非穩(wěn)定而且可能無法滿足預(yù)期的兼容性需求。范例：1.0.0-alpha、1.0.0-alpha.1、1.0.0-0.3.7、1.0.0-x.7.z.92。
(十) 版本編譯元數(shù)據(jù)可以被標(biāo)注在修訂版或先行版本號之后，先加上一個加號再加上一連串以句點分隔的標(biāo)識符來修飾。標(biāo)識符必須由 ASCII 字母數(shù)字和連接號 [0-9A-Za-z-] 組成，且禁止留白。當(dāng)判斷版本的優(yōu)先層級時，版本編譯元數(shù)據(jù)可被忽略。因此當(dāng)兩個版本只有在版本編譯元數(shù)據(jù)有差別時，屬于相同的優(yōu)先層級。范例：1.0.0-alpha+001、1.0.0+20130313144700、1.0.0-beta+exp.sha.5114f85。
(十一) 版本的優(yōu)先層級指的是不同版本在排序時如何比較。判斷優(yōu)先層級時，必須把版本依序拆分為主版本號、次版本號、修訂號及先行版本號后進(jìn)行比較（版本編譯元數(shù)據(jù)不在這份比較的列表中）。由左到右依序比較每個標(biāo)識符，第一個差異值用來決定優(yōu)先層級：主版本號、次版本號及修訂號以數(shù)值比較，例如：1.0.0 < 2.0.0 < 2.1.0 < 2.1.1。當(dāng)主版本號、次版本號及修訂號都相同時，改以優(yōu)先層級比較低的先行版本號決定。例如：1.0.0-alpha < 1.0.0。有相同主版本號、次版本號及修訂號的兩個先行版本號，其優(yōu)先層級必須透過由左到右的每個被句點分隔的標(biāo)識符來比較，直到找到一個差異值后決定：只有數(shù)字的標(biāo)識符以數(shù)值高低比較，有字母或連接號時則逐字以 ASCII 的排序來比較。數(shù)字的標(biāo)識符比非數(shù)字的標(biāo)識符優(yōu)先層級低。若開頭的標(biāo)識符都相同時，欄位比較多的先行版本號優(yōu)先層級比較高。范例：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 環(huán)境管理規(guī)范
軟件開發(fā)環(huán)境(Software Development Environment，SDE)是指在基本硬件和宿主軟件的基礎(chǔ)上，為支持系統(tǒng)軟件和應(yīng)用軟件的工程化開發(fā)和維護(hù)而使用的一組軟件，簡稱SDE。它由軟件工具和環(huán)境集成機(jī)制構(gòu)成，前者用以支持軟件開發(fā)的相關(guān)過程、活動和任務(wù)，后者為工具集成和軟件的開發(fā)、維護(hù)及管理提供統(tǒng)一的支持。環(huán)境管理規(guī)范基于業(yè)內(nèi)IT項目管理的基礎(chǔ)規(guī)范進(jìn)行整理。軟件應(yīng)用開發(fā)的經(jīng)典模型有這樣幾個環(huán)境：開發(fā)環(huán)境(DEV)、集成環(huán)境(SIT)、測試環(huán)境(TEST)、QA驗證(QA)、用戶接受度測試環(huán)境(UAT)、類生產(chǎn)環(huán)境(PRE)、生產(chǎn)環(huán)境(PROD)。而根據(jù)實際項目管理經(jīng)驗中，我們認(rèn)為最少需要4個環(huán)境進(jìn)行實際開發(fā)。
5.1 DEV環(huán)境
開發(fā)人員或者開發(fā)團(tuán)隊的工作環(huán)境，可以根據(jù)開發(fā)的需求隨時將變更更新在環(huán)境當(dāng)中用于測試，可以是開發(fā)人員的本地環(huán)境，也可以是團(tuán)隊統(tǒng)一的環(huán)境，此環(huán)境必須與其他環(huán)境和資源嚴(yán)格隔離。
5.2 SIT環(huán)境
該環(huán)境用于測試所有開發(fā)人員的代碼進(jìn)行整合之后運行環(huán)境，供測試人員使用。目前結(jié)合更為成熟的開發(fā)模式和DevOps工具，將該環(huán)境與DEV環(huán)境整合在一起，盡可能快的產(chǎn)生能夠運行測試的交付環(huán)境。
5.3 UAT環(huán)境
UAT環(huán)境主要是用來作為客戶體驗驗證測試的環(huán)境，供真實用戶驗收使用。UAT環(huán)境應(yīng)盡可能多地模擬生產(chǎn)環(huán)境，也可以兼作演示、培訓(xùn)用環(huán)境。
5.4 PROD環(huán)境
即正式環(huán)境，軟件經(jīng)過層層測試校驗后會部署在正式給用戶使用的環(huán)境，該環(huán)境由于性能要求等可能會采用分布式、集群式等復(fù)雜的架構(gòu)，部署生產(chǎn)環(huán)境是一件非常嚴(yán)肅的事情，需要避免一些可能出現(xiàn)的問題。
除以上環(huán)境之外，可根據(jù)項目管理的實際需求進(jìn)行部分調(diào)整，例如自動化測試環(huán)境、壓力測試環(huán)境、預(yù)發(fā)布環(huán)境等，其他特例環(huán)境在此不做贅述，可根據(jù)實際需求做出對應(yīng)調(diào)整。
總結(jié)
- 上一篇： Android手机通讯录制作
- 下一篇： 电子政务云