DevOps 不僅涵蓋了從開發，部署，線上監控的多個環節，還包括了組織文化，工作流程的變化，因此許多人在開始實施 DevOps 時往往覺得無從入手，或是匆忙之中採取了一些反模式，最終導致 DevOps 沒有起到預期的效果。
那麼該如何開始一個 DevOps 項目呢？或是如何啓動組織內的 DevOps 實踐呢？本文會從整個 DevOps 流程的第一步，分支模型開始，講述如果落地 DevOps。
選擇適當的分支模型
作爲整個 DevOps 的開始，你的開發分支模型是非常重要的，與你的發佈計劃與頻率息息相關。在主流的實踐中有以下的幾種選擇，我會基於自己的經驗分享各種不同模型的長處與缺陷。
基於主幹開發的分支模型
它的優點是簡單易用，如果你的團隊不大，整個團隊單純負責一款產品的開發，那麼你可以嘗試這種分支模型。
整個流程很簡單，master 即主幹分支，它對應的是隨時可以發佈上線的穩定版本，任何開發人員都不應該直接在這條分支上提交代碼。
Dev 即開發分支，所有的開發人員都在這條分支上工作，提交代碼。hotfix 分支對應的是缺陷修復分支，對應 master 版本上發現缺陷需要修改的分支。
整體的工作流程如下圖所示：
從上圖稍做修改之後就會發現，這種模型需要固定頻率的合併代碼與發佈。假設你的團隊是採用例如 Scrum 這種敏捷的工作方式，每個迭代(1 周或是 2 周)發佈一次，那麼此時 dev 代碼會自動合併到 master 分支。master 分支的代碼經過自動化測試，迴歸測試等，就可以認爲是 production ready 狀態了。
對於開發人員的要求則是要有良好的開發習慣，最好是 TDD 的擁躉，在開發一段代碼，通過 UT 後，就提交到 dev 分支，而不是開發了3，4 天之後才提交，從而避免不必要的代碼衝突。
當你的系統是個大型的單體應用，你的團隊人數衆多，又分爲數個小團隊，每個小團隊開發各自不同的 feature，那麼這種模型的缺陷就很明顯。
首先如果系統各個模塊的邊界不是那麼清晰，隔離做的不好，那麼團隊提交的代碼很可能頻繁的衝突或是破壞集成測試，造成團隊開發效率的降低。
其次固定頻率發佈的優點是有計劃，可預期發佈的功能，而隨之帶來的無法靈活的響應需求做到完成某個功能即上線。同時在一些大型團隊，發佈的頻率無法做到 2 週一次，往往是 1 個月一次，這會讓這種模式的缺陷愈加嚴重。
如果你的團隊規模不大(5 ~ 10)，開發的則是一款中小型的應用，那麼我建議你採用基於主幹開發的分支模型，快速，簡單，易於上手。
GitFlow
GitFlow 是由 Vincent Driessen 提出的一種 Git 分支模型，網上的討論很多，下面的圖片來自作者的文章。
網上對於 GitFlow 的討論已經很多了，你可以在以下的連接獲得更加詳細的信息與工具。
git-flow 備忘清單
https://danielkummer.github.io/git-flow-cheatsheet/index.zh_CN.html
在實踐中大家對於 GitFlow 的詬病之處主要在於兩點，其一是工作流程稍顯複雜，需要對開發人員做一定的培訓。其二是如果 feature 劃分不合理，出現需要開發很長週期的 feature 時，合併回 dev 分支所遇到的衝突問題會很明顯。
有部分開發人員的觀點是，除了主幹分支之外，不應該長時間的存在一個公用分支，這會造成分支合併時需要額外的時間解決代碼衝突。從精益的角度而言這是一種浪費。應該頻繁的提交到主幹版本，通過 CI 來保證主幹的穩定性。
從我的角度而言，GitFlow 在某些項目上表現的很好，但是在另一些項目上可能就存在不少的問題。但是仔細分析，這往往與 GitFlow 沒有什麼太大的關係，而是整個團隊的迭代節奏，工具的熟練程度，以及 feature 到 user story 的拆分。如果你的團隊規模在 10 人以上，對 git 的使用很有經驗，並且按照類似 Scrum 的流程運轉的很流暢，那麼我建議你可以考慮使用 GitFlow 的分支模型。
GithubFlow
從名字上可以看出，這是由 Github 提出的一種分支管理模型。下面的圖展示了工作的流程，你會發現整個流程與基於主幹的模型非常類似，只保留一條 master 主幹分支，任何一個 feature 的開發都會新建一條分支。但是在合併的過程中，GithubFlow 是依靠 PR(Pull Request)，由主幹的維護者 code review 之後再合併的。
GithubFlow 的優點也是在於簡單，基於 feature 開發。但是它嚴重依賴於團隊有健全的 code review 機制，項目需要專門留出 code review，PR 審覈的時間。之前參與過的項目中有很多 PR 的審覈流於形式，往往較爲寬鬆，只要沒有衝突就直接通過，對整個項目的代碼質量造成了很大的傷害。
反思
上面 3 種是我在之前項目中使用過的分支模型，在我做項目回顧時發現，其實並不存在一種完美的分支模型，只有適合你團隊的分支模型。但是所有這些模型的目標都只有一個，就是一定要有一條時時刻刻 production ready 的分支。同樣的任何一個分支模型都需要團隊在其他方面最佳實踐的支撐，例如規劃迭代，單元測試，user story 編寫， code review 等，具體可參考下圖。
所以這也是我在文章的一開頭就提及的，DevOps 是一個系統性，全局的實踐，其中的分支模型亦是如此。當你覺得你的分支管理十分混亂，每次發佈前在代碼集成層面麻煩不斷時，不然先看一下其他相關方面的實踐做的好不好，而不是草率的換一種分支模型，這往往會暫時解決一個老問題，又引入一個新問題。
最後，我的建議是，如果你的團隊規模不大，產品也較爲簡單，可以從基於主幹的分支模型開始。如果你的團隊已經在使用例如 Bitbucket，GitLab 等支持 PR 的工具，那麼我覺得你不妨使用 GithubFlow，培養團隊內部 code review 的習慣。知道團隊達到一定規模時，再嘗試 GitFlow。
下一篇我會介紹 DevOps 中的 CI/CD，希望你不要錯過！
相關閱讀：
小說體敏捷/DevOps轉型教科書
和實戰經驗分享
購書指南
—
紙質書、電子書在京東、噹噹、亞馬遜、微信讀書等渠道已全面上架，搜索關鍵字“獵豹 敏捷”即可找到。點擊閱讀原文可直接購書。
有聲書已登錄喜馬拉雅、微信讀書，適合路上聽書的你。
關注公衆號看其他原創作品
敏於思 捷於行
堅持每週輸出一篇高質量文章
覺得好看，點個“在看”或轉發給朋友們，歡迎你留言