代碼版本管理與軟件部署環境——從Git Flow到DTAP

缺失的拼圖

軟件開發過程當中，代碼的版本管理(Version Control)、構建部署(Build & Deployment)是大部分研發團隊必須面對的工做。

講這兩個概念的文章很是多，但不多有人專門把這兩件事放在一塊兒講。我相信不是沒有須要，而是不存在標準的流程，各個公司，甚至同一公司的每一個團隊都不同。

在這裏，我分享一些我能找到的比較權威的資料，經過分析這些信息，幫助你們瞭解代碼版本管理與部署環境完美結合的方案。

版本管理

首先來看一下版本管理，如今Git比較流行，我的、小團隊的項目，可使用免費的Github管理，若是想防止隱私數據泄露，能夠自建服務使用Gogs。公司內部可使用GitLab、或Bitbucket。

Github提供了一個簡化的工做流程，稱爲GitHub flow，小型項目能夠湊合用着，但對於大型、多版本、多人協做、高發布頻次的項目來講，徹底不夠用。

guides.github.com/introductio…

Git Flow最初是由 Vincent Driessen 提出的，請參考 nvie.com/posts/a-suc…

這是一套強大的工做流程，被不少公司所推崇，能夠搞定大部分複雜需求的項目。

構建與部署

構建部署的工做，按階段來劃分，可分爲持續集成(Continuous Integration)，持續交付(Continuous Delivery)和持續部署(Continuous Deployment)。

下圖來自 www.atlassian.com/continuous-…

能夠發現，Integration階段，須要部署到Test環境，Delivery階段，部署到Staging環境，Deployment階段部署到線上生產環境。

代碼編寫階段，是先於部署的，通常狀況下，開發者是在本身電腦上(本機Local)進行代碼編寫、編譯、運行、自測試的，也會在「開發」環境(Development)中部署，與其餘協做的開發者共同驗證功能。

到底有多少種環境（階段）？比較流行的說法是：

DTAP: development, testing, acceptance and production

能夠在Wikipedia中看到詳細解釋：en.wikipedia.org/wiki/Develo…

這裏說的Acceptance，即驗收環境，就是對應着你們所熟悉的Staging（演示環境）。因此，能夠按本身團隊的風格，將這個縮寫改成DTSP。

Git Flow & DTAP 強大的組合

Jachim Coudenys 在他的Blog中寫了一篇文章，不只講到了Git Flow和DTAP，並且還把Semver結合在一塊兒。

blog.jachim.be/2017/07/git…

你們從文章中能夠找到一些解答，但Coudenys並無畫一個簡單直觀的圖，爲了便於理解，我在這裏梳理一下這些概念的關係，以及推薦的作法。

上圖是一個簡化的流程，沒有包含全部狀況、全部細節，我相信這個推薦的作法，能夠適用於大部分團隊的工做流程。

實際上，每一個團隊能夠根據本身的狀況選用或更改。

在開發/聯調、持續集成、持續交付的階段，依據上面圖中的方式，咱們會使用不一樣的分支管理代碼。 咱們團隊用 release/* 分支發佈到 Acceptance/Staging 環境 和 Production 環境。在成功發佈後，再將代碼合併到master環境，最後再建立tag，以保留穩定代碼。

咱們還開發了一些自動化腳本，檢查當前分支潛在的問題，如是否與特定分支同步最新代碼。而且在feature開發時自動建立指向develop分支的Pull Request，在提測階段，從develop分支自動建立release/*分支。

若是你有更好的實踐方法，請留言探討。