前言

本文是學習 Git 系列的最后一篇文章, 在學習完所有 Git 的使用技巧后, 本文重點來談談開發(fā)時的一些企業(yè)級開發(fā)模型.

關注收藏, 開始學習吧??

1. 講個故事

我們知道，?個軟件從零開始到最終交付，?概包括以下?個階段：規(guī)劃、編碼、構建、測試、發(fā)布、部署和維護。

最初，程序?較簡單，?作量不?，程序員?個?可以完成所有階段的?作。但隨著軟件產業(yè)的?益發(fā)展壯?，軟件的規(guī)模也在逐漸變得龐?。軟件的復雜度不斷攀升，?個?已經hold不住了，就開始出現(xiàn)了精細化分?。如下圖所?：

但在傳統(tǒng)的 IT 組織下，開發(fā)團隊(Dev)和運維團隊(Ops)之間訴求不同：

• 開發(fā)團隊(尤其是敏捷團隊)追求變化
• 運維團隊追求穩(wěn)定

雙?往往存在利益的沖突。?如，精益和敏捷的團隊把持續(xù)交付作為?標，?運維團隊則為了線上的穩(wěn)定?強調變更控制。部?墻由此建?起來,這當然不利于 IT 價值的最?化。

為了彌合開發(fā)和運維之間的鴻溝，需要在?化、?具和實踐??的系列變??DevOps正式登上舞臺。

DevOps（Development和Operations的組合詞）是?種重視“軟件開發(fā)?員（Dev）”和“IT運維技術?員（Ops）”之間溝通合作的?化、運動或慣例。透過?動化“軟件交付”和“架構變更”的流程，來使得構建、測試、發(fā)布軟件能夠更加地快捷、頻繁和可靠。在DevOps的軟件開發(fā)過程包含計劃、編碼、構建、測試、預發(fā)布、發(fā)布、運維、監(jiān)控，由此可?DevOps的強?。

講了這么多，這個故事到底和我們系列的主題 Git 有什么關系呢？

舉?個很簡單的例?就能說明這個問題。?個軟件的迭代，在我們開發(fā)?員看來，說?了就是對代碼進?迭代，那么就需要對代碼進?管理。如何管理我們的代碼呢，那不就是 Git（分布式版本控制系統(tǒng)） ！所以 Git 對于我們開發(fā)?員來說其重要性就不??喻了。

2. 系統(tǒng)開發(fā)環(huán)境

?歸正傳，對于開發(fā)?員來說，在系統(tǒng)開發(fā)過程中最常?的?個環(huán)境必須要了解?下：

1. 開發(fā)環(huán)境：開發(fā)環(huán)境是程序猿們專??于?常開發(fā)的服務器。為了開發(fā)調試?便，?般打開全部錯誤報告和測試?具，是最基礎的環(huán)境。
2. 測試環(huán)境：?個程序在測試環(huán)境?作不正常，那么肯定不能把它發(fā)布到?產機上。該環(huán)境是開發(fā)環(huán)境到?產環(huán)境的過渡環(huán)境。
3. 預發(fā)布環(huán)境：該環(huán)境是為避免因測試環(huán)境和線上環(huán)境的差異等帶來的缺陷漏測?設?的?套環(huán)境。其配置等基本和?產環(huán)境?致，?的是能讓我們發(fā)正式環(huán)境時更有把握！所以預發(fā)布環(huán)境是你的產品質量最后?道防線，因為下?步你的項?就要上線了。要注意預發(fā)布環(huán)境服務器不在線上集成服務器范圍之內，為單獨的?些機器。
4. ?產環(huán)境：是指正式提供對外服務的線上環(huán)境，例如我們?前在移動端或PC端能訪問到的APP都是?產環(huán)境。

這?個環(huán)境也可以說是系統(tǒng)開發(fā)的三個重要階段：開發(fā)->測試->上線。?張圖總結：

對于規(guī)模稍微?點的公司來說，可不?這么?個環(huán)境，?如項?正式上線前還存在仿真/灰度環(huán)境，再?如還存在多套測試環(huán)境，以滿?不同版本上線前測試的需要。

?個項?的開始從設計開始，??個項?的成功則從測試開始。?套良好的測試體系可以將系統(tǒng)中絕?部分的致命Bug 解決在系統(tǒng)上線之前。測試系統(tǒng)的完善和成熟也是衡量?個軟件企業(yè)整體?平的重要指標之?，測試往往被忽視，因為它對可以的隱性、對軟件開發(fā)企業(yè)不產?直接的效益，但是它卻是軟件質量的最終保障，乃?項?能否成功的重要因素！

3. Git 分支設計規(guī)范

環(huán)境有了概念后，那么對于開發(fā)?員來說，?般會針對不同的環(huán)境來設計分?，例如：

注：以上表格中的分?和環(huán)境的搭配僅是常?的?種，可視情況?定不同的策略。

3.1 master 分支

• master 為主分?，該分?為只讀且唯?分?。?于部署到正式發(fā)布環(huán)境，?般由合并 release 分?得到。
• 主分?作為穩(wěn)定的唯?代碼庫,任何情況下不允許直接在 master 分?上修改代碼。
• 產品的功能全部實現(xiàn)后，最終在 master 分?對外發(fā)布，另外所有在 master 分?的推送應該打標簽（tag）做記錄，?便追溯。
• master 分?不可刪除。

3.2 release 分支

• release 為預發(fā)布分?，基于本次上線所有的 feature 分?合并到 develop 分?之后，基于 develop 分?創(chuàng)建?？梢圆渴鸬綔y試或預發(fā)布集群。
• 命名以 release/ 開頭，建議的命名規(guī)則: release/version_publishtime 。
• release 分?主要?于提交給測試?員進?功能測試。發(fā)布提測階段，會以 release 分?代碼為基準進?提測。
• 如果在 release 分?測試出問題，需要回歸驗證 develop 分?看否存在此問題。
• release 分?屬于臨時分?，產品上線后可選刪除。

3.3 develop 分支

• develop 為開發(fā)分?，基于 master 分?創(chuàng)建的只讀且唯?分?，始終保持最新完成以及 bug 修復后的代碼?？刹渴鸬介_發(fā)環(huán)境對應集群。
• 可根據(jù)需求??程度確定是由 feature 分?合并，還是直接在上?開發(fā)（?常不建議）。

3.4 feature 分支

• feature 分?通常為新功能或新特性開發(fā)分?，以 develop 分?為基礎創(chuàng)建 feature 分?。
• 命名以 feature/ 開頭，建議的命名規(guī)則： feature/user_createtime_feature 。
• 新特性或新功能開發(fā)完成后，開發(fā)?員需合到 develop 分?。
• ?旦該需求發(fā)布上線，便將其刪除。

3.5 hotfix 分支

• hotfix 分?為線上 bug 修復分?或叫補丁分?，主要?于對線上的版本進? bug 修復。當線上出現(xiàn)緊急問題需要?上修復時，需要基于 master 分?創(chuàng)建 hotfix 分?。
• 命名以 hotfix/ 開頭，建議的命名規(guī)則: hotfix/user_createtime_hotfix 。
• 當問題修復完成后，需要合并到 master 分?和 develop 分?并推送遠程。?旦修復上線，便將其刪除。

?張圖總結：

其實，以上跟?家談的是企業(yè)級常?的?種 Git 分?設計規(guī)范：Git Flow 模型。但要說的是，該模型并不是適?于所有的團隊、所有的環(huán)境和所有的?化。如果你采?了持續(xù)交付，你會想要?些能夠盡可能簡化交付過程的東西。有些?喜歡基于主?的開發(fā)模式，喜歡使?特性標志。然?，從測試的?度來看，這些反?會把他嚇?跳。

關鍵在于站在你的團隊或項?的?度思考：這種分?模型可以幫助你們解決哪些問題？它會帶來哪些問題？這種模式為哪種開發(fā)提供更好的?持？你們想要?勵這種?為嗎？你選擇的分?模型最終都是為了讓?們更容易地進?軟件協(xié)作開發(fā)。因此，分?模型需要考慮到使?者的需求，?不是盲?聽信某些所謂的“成功的分?模型”。

所以對于不同公司，規(guī)范是會有些許差異，但萬變不離其宗，是為了效率與穩(wěn)定。

4. 修復問題建議

4.1 修復測試環(huán)境 Bug

在 develop 測試出現(xiàn)了 Bug，建議?家直接在 feature 分?上進?修復。

修復后的提測上線流程 與 新需求加?的流程?致。

4.2 修改預發(fā)布環(huán)境 Bug

在 release 測試出現(xiàn)了 Bug，?先要回歸下 develop 分?是否同樣存在這個問題。

• 如果存在，修復流程 與 修復測試環(huán)境 Bug流程?致。
• 如果不存在，這種可能性?較少，?部分是數(shù)據(jù)兼容問題，環(huán)境配置問題等。

4.3 修改正式環(huán)境 Bug

在 master 測試出現(xiàn)了 Bug，?先要看下 release 和 develop 分?是否同樣存在這個問題。

• 如果存在，修復流程 與 修復測試環(huán)境 Bug 流程?致。
• 如果不存在，這種可能性也?較少，?部分是數(shù)據(jù)兼容問題，環(huán)境配置問題等。

4.4 緊急修復正式環(huán)境 Bug

需求在測試環(huán)節(jié)未測試出 Bug，上線運??段時候后出現(xiàn)了 Bug，需要緊急修復的。

有的企業(yè)?對緊急修復時，?持不進?測試環(huán)境的驗證，但還是建議驗證下預發(fā)布環(huán)境。

可基于 master 創(chuàng)建 hotfix/xxx 分?，修復完畢后發(fā)布到 master 驗證，驗證完畢后，將 master 代碼合并到 develop 分?，同時刪掉 hotfix/xxx 分?

拓展閱讀
阿??流flow分?模型，及項?版本管理實踐

總結

? 想了解更多知識, 請持續(xù)關注博主, 本人會不斷更新學習記錄, 跟隨我一起不斷學習 -> 跳轉Git專欄.
? 感謝你們的耐心閱讀, 博主本人也是一名學生, 也還有需要很多學習的東西. 寫這篇文章是以本人所學內容為基礎, 日后也會不斷更新自己的學習記錄, 我們一起努力進步, 變得優(yōu)秀, 小小菜鳥, 也能有大大夢想, 關注我, 一起學習.

再次感謝你們的閱讀, 你們的鼓勵是我創(chuàng)作的最大動力!!!!!文章來源地址http://www.zghlxwxcb.cn/news/detail-765148.html

到了這里，關于【Git 小妙招】來淺淺聊一下企業(yè)級開發(fā)模型的文章就介紹完了。如果您還想了解更多內容，請在右上角搜索TOY模板網以前的文章或繼續(xù)瀏覽下面的相關文章，希望大家以后多多支持TOY模板網！