版本控制指引

版本控制指引概念產(chǎn)品版本項(xiàng)目/子項(xiàng)目所定義的版本，兩節(jié)：x.y。如智計(jì)劃1.2，那么這個(gè)產(chǎn)品版本號(hào)為1.2。工程版本代碼構(gòu)建產(chǎn)物的版本。工程版本號(hào)通常為四節(jié),x.y.z.build。x.y繼承產(chǎn)品版本號(hào)；z在敏捷項(xiàng)目團(tuán)隊(duì)中是沖刺編號(hào)，在瀑布團(tuán)隊(duì)中為流水號(hào)。該節(jié)用于區(qū)分不同的研發(fā)、上線周期；build為構(gòu)建流水號(hào)，通常由構(gòu)建工具自動(dòng)生成。測(cè)試代碼同樣也有工程版本號(hào)。目前測(cè)試代碼沒(méi)有發(fā)布流程，也沒(méi)有通過(guò)工具發(fā)布，所以z.build由測(cè)試團(tuán)隊(duì)人員自行決定。原則上每一次正式交付，變更z。發(fā)布標(biāo)簽每一次發(fā)布到生產(chǎn)，在git代碼庫(kù)中，給對(duì)應(yīng)的commit標(biāo)記一個(gè)標(biāo)簽，值為部署物的工程版本，即x.zy.z.build。目標(biāo)統(tǒng)一分支管理策略以及定義。版本化一切，最終提高項(xiàng)目的團(tuán)隊(duì)合作效率、加速新功能開(kāi)發(fā)和發(fā)布管理。原則采用GitHubFlow策略（推薦）或基于主干開(kāi)發(fā)策略。要求項(xiàng)目有完善的自動(dòng)化測(cè)試、持續(xù)集成和部署等相關(guān)的基礎(chǔ)設(shè)施。版本化一切。團(tuán)隊(duì)有代碼審查的相應(yīng)流程。具備自動(dòng)部署的條件規(guī)范代碼倉(cāng)庫(kù)必須：代碼應(yīng)放在集團(tuán)統(tǒng)一的代碼倉(cāng)庫(kù)。必須：工程的可見(jiàn)性不能設(shè)置為public。必須：只允許給項(xiàng)目相關(guān)開(kāi)發(fā)人員配置權(quán)限，并應(yīng)該遵循最小授權(quán)原則。必須：代碼項(xiàng)目創(chuàng)建在團(tuán)隊(duì)空間內(nèi)，不允許放在個(gè)人空間。建議：團(tuán)隊(duì)空間命名格式為：group/[subgroup]。group為產(chǎn)品線簡(jiǎn)稱，如果產(chǎn)品線有多個(gè)子產(chǎn)品，再加上subgroup。subgroup為子產(chǎn)品簡(jiǎn)稱。如gaia/gfs，group=gaia，subgroup=gfs。建議：代碼項(xiàng)目命名格式為：項(xiàng)目代號(hào)-模塊[-子模塊][-孫模塊]。如：gaia-gfs-demo，halo-wechat。這樣，GIT中完整的空間-項(xiàng)目名為：gaia/gfs/gaia-gfs-demo。分支命名【GitHubFlow】必須：master分支被保護(hù)，不允許直接提交至master。必須：創(chuàng)建分支使用有意義的名稱頭，功能開(kāi)發(fā)用feature/{JIRA編號(hào)}-*，bug修復(fù)用bug/{JIRA編號(hào)}-*，熱修復(fù)用hotfix/{JIRA編號(hào)}-*。如feature/XM1907901-1390-enable_audit_log_for_inventory,bug/XM1907901-1403-xxxxxxx。建議：創(chuàng)建分支開(kāi)始后，就創(chuàng)建一個(gè)MR，用于描述思路，并記錄討論過(guò)程。建議：未完成的MR以WIP:開(kāi)頭，如：“WIP:用戶1分鐘未有動(dòng)作，自動(dòng)鎖屏”。必須：至少有一個(gè)成員同意合并，才允許合并分支。建議：合并分支時(shí)，使用--squash，或選中g(shù)itlab界面上的"[X]Squashcommitswhenmergerequestisaccepted"。版本必須：每一次準(zhǔn)備發(fā)布生產(chǎn)的交付物，打上發(fā)布標(biāo)簽，并記錄ReleaseNotes。建議：數(shù)據(jù)庫(kù)有版本號(hào)。不同版本的數(shù)據(jù)庫(kù)變更腳本，支持冪等操作，以便自動(dòng)化完成升級(jí)/降級(jí)。建議：測(cè)試用例、測(cè)試數(shù)據(jù)也有版本號(hào)，要么和代碼工程版本一致，要么自定義，和代碼工程版本有對(duì)應(yīng)關(guān)系。建議：推薦使用Flyway，EntityFrameworkMigrations來(lái)管理DB版本。推薦實(shí)踐版本號(hào)使用場(chǎng)景敏捷項(xiàng)目沖刺開(kāi)始，定義本沖刺版本的前三節(jié)。提交、解決、關(guān)閉bug時(shí)，正確填入了DevOps中對(duì)應(yīng)的工程版本號(hào)。DevOps構(gòu)建時(shí)，根據(jù)前三節(jié)，自動(dòng)補(bǔ)充最后一節(jié)的編譯流水號(hào)。發(fā)布至生產(chǎn)環(huán)境時(shí)，DevOps根據(jù)工程版本，自動(dòng)生成tag標(biāo)簽。如果只通過(guò)DevOps部署，則沒(méi)有沖刺版本。DevOps根據(jù)產(chǎn)品版本，自動(dòng)加上制品的上傳批次號(hào)，如1.2.13，以追蹤各環(huán)境和不同版本部署物的對(duì)應(yīng)關(guān)系。假設(shè)場(chǎng)景項(xiàng)目名稱開(kāi)發(fā)啟動(dòng)時(shí)間移交測(cè)試時(shí)間回歸時(shí)間上線時(shí)間XX項(xiàng)目9月1日9月15日9月25日9月26日開(kāi)發(fā)流程序號(hào)時(shí)間事項(xiàng)描述命令說(shuō)明19月1日從master新建分支從master創(chuàng)建分支。分支名稱：

feature/11-Add_redis_supportgitcheckoutmastergitpullgitcheckout-bfeature/11-add_redis_supportgitpush--set-upstreamoriginfeature/11-add_redis_support所有參與人員都提交到此分支29月2日設(shè)計(jì)、編寫代碼與測(cè)試提交、提交、提交gitadd--allgitcommit-a-m"movedisplaynametoredis"gitpush39月3日開(kāi)啟MR，以開(kāi)啟討論和Review從gitlab的站點(diǎn)中創(chuàng)建一個(gè)MR。如果并未做完，MR以"WIP:"開(kāi)頭49月15日討論、修改、測(cè)試討論方案、修正review的改進(jìn)項(xiàng)。gitadd.59月16日循環(huán)修復(fù)bug并不斷push到遠(yuǎn)程分支。gitcommit-am"moveonandon"6……每日mergemaster代碼到分支。gitmergemaster79月25日自動(dòng)化、人工驗(yàn)收全部通過(guò)，MR通過(guò)master代碼可以發(fā)布時(shí)，打上版本號(hào)標(biāo)簽，1.1.0gittagadd"1.1.0"gitpush--tag選中"Squashcommitswhenmergerequest