前言
拓展
我們知道,一個(gè)軟件從零開始到最終交付,大概包括一下幾個(gè)階段 : 規(guī)劃、編碼、構(gòu)建、測試、發(fā)布、部署和維護(hù).
最初程序比較簡單,工作量也不大.程序猿一個(gè)人可以完成所有階段的工作.但隨著軟件產(chǎn)業(yè)的日益發(fā)展壯大,軟件的規(guī)模也在逐漸變得龐大.軟件的復(fù)雜度不斷攀升,一個(gè)人已經(jīng)hold不住了,就開始出現(xiàn)了精細(xì)化分工.如下圖所示 :
但在傳統(tǒng)的IT組織下,開發(fā)團(tuán)隊(duì)(Dev)和運(yùn)維團(tuán)隊(duì)(Ops)之間的訴求不同 :
- 開發(fā)團(tuán)隊(duì)(尤其是敏捷團(tuán)隊(duì))追求變化
- 運(yùn)維團(tuán)隊(duì)穩(wěn)定
雙方往往存在利益的沖突.比如,精益和敏捷的團(tuán)隊(duì)把持續(xù)交付作為目標(biāo),而運(yùn)維團(tuán)隊(duì)則為了線上的穩(wěn)定而強(qiáng)調(diào)變更控制.部門墻由此建立起來,這當(dāng)然不利于IT價(jià)值的最大化.
為了彌補(bǔ)開發(fā)和運(yùn)維之間的鴻溝,需要在文化、工具和實(shí)踐方面的系列改革—DevOps正式登上舞臺(tái).
DevOps(Development和Operations的組合詞)是一種重視"軟件開發(fā)人員(Dev)"和"IT運(yùn)維技術(shù)人員(Ops)"之間溝通合作的文化、運(yùn)動(dòng)或慣例.通過自動(dòng)化"軟件交付"和"架構(gòu)變更"的流程,來使得構(gòu)建、測試、發(fā)布軟件能夠更加地快捷、頻繁和可靠.在DevOps的軟件開發(fā)過程包含計(jì)劃講了這么多,這個(gè)故事到底和Git有什么關(guān)系呢?
舉一個(gè)很簡單的例子就能說明這個(gè)問題.一個(gè)軟件的迭代,在我們開發(fā)人員看來,說白了就是對(duì)代碼進(jìn)行迭代,那么就需要對(duì)代碼進(jìn)行管理.如何管理我們的代碼呢,那不就是Git(分布式版本控制系統(tǒng))!!! 所以Git對(duì)于我們開發(fā)人員來說其重要性就不言而喻了!!!
正文開始!!!
一、系統(tǒng)開發(fā)環(huán)境
言歸正傳,對(duì)于開發(fā)人員來說,在系統(tǒng)開發(fā)過程中最常用的幾個(gè)環(huán)境必須要了解一下 :
- 開發(fā)環(huán)境 : 開發(fā)環(huán)境是程序猿們專門用于日常開發(fā)的服務(wù)器.為了開發(fā)調(diào)試方便,一般打開全部錯(cuò)誤報(bào)告和測試工具,是最基礎(chǔ)的環(huán)境.
- 測試環(huán)境 : 一個(gè)程序在測試環(huán)境工作不正常,那么肯定是不能把它發(fā)布到生產(chǎn)機(jī)上.該環(huán)境是開發(fā)環(huán)境到生產(chǎn)環(huán)境的過渡環(huán)境.
- 預(yù)發(fā)布環(huán)境 : 該環(huán)境是為避免因測試環(huán)境和線上環(huán)境的差異等帶來的缺陷漏測而設(shè)立的一套環(huán)境.其配置等基本和生產(chǎn)環(huán)境一致,目的是能讓我們發(fā)布正式環(huán)境時(shí)更有把握!所以預(yù)發(fā)布環(huán)境是你的產(chǎn)品質(zhì)量的最后一道防線,因?yàn)橄乱徊侥愕捻?xiàng)目就要上線了.要注意預(yù)發(fā)布環(huán)境服務(wù)器不在線上集成服務(wù)器范圍之內(nèi),為單獨(dú)的一些機(jī)器.
- 生產(chǎn)環(huán)境 : 是指正式提供對(duì)外服務(wù)的線上環(huán)境,例如我們目前在移動(dòng)端或PC端能訪問到的APP都是生產(chǎn)環(huán)境.
對(duì)于規(guī)模稍微大點(diǎn)的公司來說,可不止這幾個(gè)環(huán)境,比如項(xiàng)目正式上線前還存在仿真/灰度環(huán)境,再比如還存在多套測試環(huán)境,以滿足不同版本上線前測試的需要.
一個(gè)項(xiàng)目的開始從設(shè)計(jì)開始,而一個(gè)項(xiàng)目的成功則從測試開始.一套良好的測試體系可以將系統(tǒng)中絕大部分的致命Bug在系統(tǒng)上線之前解決.測試系統(tǒng)的完善和成熟也是衡量一個(gè)軟件企業(yè)整體水平的重要指標(biāo)之一,測試往往被忽略,因?yàn)樗麑?duì)可以的隱性、對(duì)軟件開發(fā)企業(yè)不產(chǎn)生直接的效益,但是它確是軟件質(zhì)量的最終保障,乃至項(xiàng)目能否成功的重要因素!
二、Git分支設(shè)計(jì)規(guī)范
分支 | 名稱 | 適用環(huán)境 |
---|---|---|
master | 主分支 | 生產(chǎn)環(huán)境 |
release | 預(yù)發(fā)布版本 | 預(yù)發(fā)布/測試環(huán)境 |
develop | 開發(fā)分支 | 開發(fā)環(huán)境 |
feature | 需求開發(fā)分支 | 本地 |
hotfix | 緊急修復(fù)分支 | 本地 |
注 : 以上表格中的分支和環(huán)境的搭配僅是常用的一種,可視情況而定不同的策略.
master分支
-
master
為主分支,該分支為只讀且唯一分支.用于部署到正式發(fā)布環(huán)境,一般由合并release
分支得到. - 主分支作為穩(wěn)定的唯一代碼庫,任何情況下不允許直接在master分支上修改代碼.
- 產(chǎn)品的功能全部實(shí)現(xiàn)后,最終在master分支對(duì)外發(fā)布,另外所有在master分支的推送應(yīng)該打標(biāo)簽(tag)做記錄,方便追溯.
- master分支不可刪除.
release分支
-
release
為預(yù)發(fā)布分支,基于本次上線所有的feature
分支合并到develop
分支之后,基于develop
分支創(chuàng)建.可以部署到測試灬預(yù)發(fā)布集群. - 命名以
release/
開頭,建議的命名規(guī)則 :release/version_publishtime
. -
release
分支主要用于提交給測試人員進(jìn)行功能測試.發(fā)布提測階段,會(huì)以release
分支代碼為基準(zhǔn)進(jìn)行提測. - 如果在
release
分支測試出問題,需要回歸驗(yàn)證develop
分支查看是否存在此問題. -
release
分支屬于臨時(shí)分支,產(chǎn)品上線后可選刪除.
develop分支
-
develop
為開發(fā)分支,基于master分支創(chuàng)建的只讀且唯一分支,始終保持最新完成以及Bug修復(fù)后的代碼.可部署到開發(fā)環(huán)境對(duì)應(yīng)集群. - 可根據(jù)需求大小程度確定是由
feature
分支合并,還是直接在上面開發(fā)(非常不建議).
feature分支
-
feature
分支通常為新功能或新特性開發(fā)分支,以develop
分支為基礎(chǔ)創(chuàng)建feature
分支. - 命名以
feature/
開頭,建議命名規(guī)則 :feature/user_createtime_feature
. - 新特性或新功能開發(fā)完成后,開發(fā)人員需合到
develop
分支. - 一旦該需求發(fā)布上線,便將其刪除.
hotfix分支
-
hotfix
分支為線上Bug修復(fù)分支或補(bǔ)丁分支,主要用于對(duì)線上的版本進(jìn)行Bug修復(fù).當(dāng)線上出現(xiàn)緊急問題需要馬上修復(fù)時(shí),需要基于master
分支創(chuàng)建hotfix
分支. - 命名以
hotfix/
開頭,建議的命名規(guī)則 :hotfix/user_createtime_hotfix
. - 當(dāng)問題修復(fù)完成后,需要合并到
master
分支和develop
分支并推送遠(yuǎn)程.一旦修復(fù)上線,便將其刪除.
?張圖總結(jié):
其實(shí),以上是企業(yè)級(jí)常用的一種Git分支設(shè)計(jì)規(guī)范 : Git Flow 模型.但要說的是,該模型并不是適用于所有的團(tuán)隊(duì)、所有的環(huán)境和所有的文化.如果你才用了持續(xù)交付,你會(huì)想要一些能夠盡可能簡化交付過程的東西.有些人喜歡基于主干的開發(fā)模式,喜歡使用特性標(biāo)志.然而,從測試的角度來看,這些反而會(huì)把他嚇一跳.
關(guān)鍵在于站在你團(tuán)隊(duì)或項(xiàng)目的角度思考 : 這種分支模型可以幫助你們解決那些問題?這種模式為哪種開發(fā)提供更好的支持?你們想要鼓勵(lì)這種行為嗎?你選擇的分支模型最終都是為了讓人們更容易地進(jìn)行軟件協(xié)作開發(fā).因此,分支模型需要考慮到使用者的需求,而不是盲目聽信某些所謂的"成功的分支模型".
所以對(duì)于不同公司,規(guī)范是會(huì)有些許差異,但萬變不離其宗,是為了效率和穩(wěn)定.
三、企業(yè)級(jí)項(xiàng)目管理實(shí)戰(zhàn)
準(zhǔn)備工作
DevOps研發(fā)平臺(tái)
Gitee企業(yè)版免費(fèi)
企業(yè)名稱可隨意填寫?個(gè)測試名稱,只要能通過即可。注意,多?協(xié)作開發(fā),需要將多?賬號(hào)拉入一個(gè)企業(yè)下才行。
創(chuàng)建項(xiàng)目
創(chuàng)建倉庫
注:創(chuàng)建的倉庫可以關(guān)聯(lián)到某個(gè)項(xiàng)?中被管理
添加成員
1. 添加企業(yè)成員
申請(qǐng)后需要負(fù)責(zé)人審批通過.
2.添加項(xiàng)目成員
3. 添加倉庫開發(fā)?員
開發(fā)場景-基于git flow模型的實(shí)踐
新需求加入
現(xiàn)有一個(gè)訂單管理的新需求需要開發(fā),首先可以基于develop
分支創(chuàng)建一個(gè)feature/rose_20230710_pay
分支.
- 需求在
feature/rose_20230710_pay
分支開發(fā)完畢,這是研究人員可以將代碼合并到develop
分支,將其部署在開發(fā)環(huán)境的服務(wù)器中,方便開發(fā)人員進(jìn)行測試和調(diào)試.
a. 開發(fā)者在feature
分支下發(fā)起請(qǐng)求評(píng)審
b. 審查員審查代碼
c. 審查通過,合并分?
d. 合并成功,查看結(jié)果
2. 在 develop 下開發(fā)?員?測通過后,先確定下 develop 不存在未測試完畢的需求,然后研發(fā)?員可基于 develop 分?創(chuàng)建?個(gè) release/xxx 分?出來,可交由測試?員進(jìn)?測試
3. 測試?員測試 release 通過后(包含測試環(huán)境和預(yù)發(fā)布環(huán)境的測試),就可將代碼合并?master.
4. 測試?員在 master (正式環(huán)境) 測試通過后,便可刪除 feature/xxx 分?.
修復(fù)測試環(huán)境Bug
在develop
測試出現(xiàn)了Bug,建議大家直接在feature
分支上進(jìn)行修復(fù).
修復(fù)后的提測上線流程與新需求加入的流程一致.
修復(fù)預(yù)發(fā)布環(huán)境Bug
在release
測試出現(xiàn)了Bug,首先要回歸develop
分支是同樣存在這個(gè)問題.
如果存在,修復(fù)流程與修復(fù)測試環(huán)境Bug流程一致.
如果不存在,這種可能性比較小,大部分是數(shù)據(jù)兼容問題,環(huán)境配置問題等.
修復(fù)正式環(huán)境Bug
在master
測試出現(xiàn)了Bug,首先要回歸下release
和develop
分支是否同樣存在這個(gè)問題.
如果存在,修復(fù)流程與修復(fù)測試環(huán)境Bug流程一致.
如果不存在,這種可能性也比較小,大部分是數(shù)據(jù)兼容問題,環(huán)境配置問題等.
緊急修復(fù)正式環(huán)境Bug
需求在測試環(huán)節(jié)未測試出Bug,上線一段時(shí)候后出現(xiàn)了Bug,需要緊急修復(fù)的.
有的企業(yè)面對(duì)緊急修復(fù)時(shí),支持不進(jìn)行環(huán)境測試的驗(yàn)證,但還是建議驗(yàn)證下預(yù)發(fā)布環(huán)境.
科技與master
分支創(chuàng)建hotfix/xxx
分支,修復(fù)完畢后發(fā)布到master
驗(yàn)證,驗(yàn)證完畢后,將master
分支合并到develop
分支,同時(shí)刪除掉hot/xxx
分支.文章來源:http://www.zghlxwxcb.cn/news/detail-546912.html
總結(jié)
至此,關(guān)于Git的學(xué)習(xí)就告一段落啦!!!
希望大家有問題可以積極的私信我!!!文章來源地址http://www.zghlxwxcb.cn/news/detail-546912.html
到了這里,關(guān)于Git---企業(yè)級(jí)開發(fā)模型的文章就介紹完了。如果您還想了解更多內(nèi)容,請(qǐng)?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章,希望大家以后多多支持TOY模板網(wǎng)!