CakeDC Git workflow是一個項目開發和版本發佈的工做流,在這個工做流程中開發和版本發佈週期是基於幾個關鍵階段(key phases):git
全部活躍的開發活動都由里程碑驅動,在這個階段的產出是很不穩定的代碼基線服務器
Quality assurance testing做爲一開發週期的一部分,主要協助確保需求的知足性和質量的可接受性app
客戶或者評審員面對的是一個穩定的代碼基線,該基線已經通過了QA流程,質量上已經被QA人員承認測試
發佈版本在QA和review評審流程都順利完成以後的產物。ui
cakeDC所使用的workflow設計是基於vincent driessen的gitflow推薦,雖然他們有一些類似性,可是也有部分的裁剪和修改,可能更加適合於較大型團隊,有正式流程的項目開發this
Organization:spa
本workflow設計的主要思想是它能適合於集成一個QA流程做爲他們開發流程一部分的團隊或公司,同時給客戶提供一個穩定的stage server來review和approve the pending release。然而,若是你沒有QA流程,或者不提供stage server for customer review/approve,這些步驟也能夠輕易地被忽略。設計
貫穿各個phase咱們項目的整個開發和發佈被劃分爲幾個不一樣階段的目標,咱們稱之爲milestones。一個milestone自己並不等同於一個release.一個項目的一個版本能夠由多個milestone構成,這依賴於項目的計劃和資源情況。code
這些phases由"permanent永久"和"temporary臨時"的分支來表明,經過這些phase,推動咱們的開發流程向一個release的正確方向邁進。須要一個持續性的分支的緣由是爲了準備各類部署需求,容許每個人在項目開發不一樣階段產品的狀態有一個清晰地認識。這兩種分支包含下面的git branches,而這將造成咱們的work flow的一部分。server
Permanent braches:
1.develop
也被稱爲bleeding edge(前沿),這個分支包含爲當前milestone準備的已經結束的features。這是一個alpha狀態的代碼基線,每每被認爲是很是不穩定的。
2.qa
全部爲了一個milestone而作的開發活動最終在這個分支上來作驗證和測試。這是一個beta階段的代碼基線,也被認爲是不穩定的。
3.stage
一旦爲了一個milestone作的開發工做經過了QA測試,那麼就能夠用這個分支來host stable code base for review.
4.master
若是上述stage分支的代碼由客戶或者評審人員approval了,那麼stage分支的代碼就merge到master,而這個master分支將在生產環境保留項目的當前穩定版本。
Temporary branches:
1.feature
這些分支是從develop分支上建立出來,目的是爲了隔離一個特定任務的開發工做。feature自己的定義每每很大程度上與管理風格有關,好比milestone是一個長的或短的sprints。
2.issue
這些分支從qa分支上建立,目的是爲了解決完整測試一個milestone的軟件的QA階段報出的問題
3.hot-fix
這些分支是由生產環境中報出的緊急問題而觸發的。最好的狀況下,這些分支將永遠不會建立,由於咱們通過QA流程,質量獲得了很好的保證
「永久」和「臨時」的分支的重要區別是:對於permanent分支,永遠不會在這個分支上直接修改代碼commit代碼,永久分支上永遠是經過merge臨時分支而獲得相關代碼的。完整的流程以下:
在下面的章節中,開發和版本發佈的各個階段phases將會分別描述,詳細講解各個流程
Development:
在一個milestone的實際開發活動中,開發人員將從develop分支建立feature branch
這些分支命名爲"feature/xxx"。xxx一般對應着項目管理系統中的一個ticket,好比
$ git checkout -b feature/1234 develop $ git push -u origin feature/1234
經過將開發任務隔離到一個獨立的分支上,開發人員可以有效避免destablize develop分支,以避免影響他人的工做。並且,若是有些feature是基於其餘的feature,那麼這個feature分支能夠被其餘已經commit到develop分支的feature作updated(rebase)
若是你和其餘的開發人員在作同一個feature,那麼你能夠checkout他們的分支,而且協同工做。
$ git checkout -t origin/feature/1234
當一個feature開發結束,它將被merge back to develop分支,feature分支自己能夠被刪除了。
$ git checkout develop $ git merge --no-ff feature/1234 $ git branch -d feature/1234 $ git push origin :feature/1234
develop分支自己本認爲是不穩定的,因此最好開發人員能有一個部署這個branch的服務器,這樣他們可以輕易地修改項目的bleeding edge version of the project,輔助討論或者提供一個review當前進展的方式。這也幫助那些對開發流程不是很是清晰地項目經理獲取到將要到來的milestone的真實狀態。
Testing:
當一個milestone被認爲完成時,develop分支將被merge到qa分支,QA流程啓動:
很是重要一點:當develop分支被merge到qa分支時,全部的新features將構成了下一個milestone.這就容許對當前milestone的測試和對下一個milestone的開發工做徹底並行化了。另外,因爲QA流程是在一個專用的branch上進行的,這就容許測試階段能夠在不影響繼續開發的前提下來作規劃和執行。
$ git checkout qa
$ git merge --no-ff develop
在測試階段,QA可能發現這個milestone的一些issues,也就是說有些feature是fail掉的。當這種事情發生時,爲了解決這些bug咱們將要從qa分支上來建立issue分支。這些分支被命名爲"issue/xxxx",xxxx表明了你的項目管理或者bug tracking系統中的一個id,好比:
$ git checkout -b issue/1234 qa $ git push -u origin issue/1234
當這個issue branch存續期間,若是這個問題自己依賴於另一個issue的結束,那麼這個issue branch自己也能夠被其餘已經被commit到qa分支上的其餘issue的commit來作updated/rebased。當問題解決了,merge到qa分支,而後這個issue分支就被刪除了
$ git checkout qa $ git merge --no-ff issue/1234 $ git branch -d issue/1234 $ git push origin :issue/1234
在QA階段,一個專用的測試服務器應該是必須的。這個服務器部署qa分支的代碼,專門用於QA團隊來作測試使用。
Review:
一旦一個milestone貫穿了實際的開發活動,而且完成了QA流程,新的功能如今就能夠放到stage分支上作review了。
在這裏qa分支將被merge到stage分支上,同時qa分支也須要merge到develop分支上去,以便爲未來的milestone來使用:
$ git checkout develop $ git merge --no-ff qa $ git checkout stage $ git merge --no-ff qa
並且,爲了標示milestone的結束,應該從stage分支上打一個tag,這些tag被命名爲"milestone/xxxx" xxxx是一個milestone id,一般就是一個序數。
$ git tag -a milestone/1
stage分支如今能夠部署到一個staging server上去了,能夠邀請客戶或者評審人員來review和評審。若是任何問題被發現或者新的功能在這個時間被要求,那麼他們就將成爲在develop分支上的當前active milestone的開發任務,或者能夠計劃到未來的開發任務中去。
在qa或者stage分支上,不容許直接修改commit,只容許經過feature分支merge到develop分支,隨後經過QA流程。尊重這個流程很是重要,然而可能不少組織就直接在stage分支上打patch了,由於這將破壞QA流程。
Release:
當stage分支經過了review,在完成一個或多個milestone以後,一個release能夠被建立了。這將是更新生產服務器代碼的時
機了。
爲了建立release,stage分支須要merge到master,另外,爲了建立一個release,一個tag須要再master分支上打上。這些tags命名爲"release/xxx" xxx爲version number。
$ git checkout master $ git merge --no-ff stage $ git tag -a release/1.1.0
全部在本release以後從qa merge到stage的代碼都構成了下一個版本的應用。
Hot Fixes:
在生產環境中,有時可能會發現一些重大問題,而用戶又不能等到下一個release來解決,這時就須要用到hotfix了。
在這種狀況下,一個hot-fix分支須要從master分支上建立,這些分支被命名爲「hot-fix/xxx"xxx爲bugid:
$ git checkout -b hot-fix/1234 master $ git push -u origin hot-fix/1234
依賴於QA的需求,可能須要再問題解決後,就在hot-fix分支上來作驗證。有3中方法:
1.Kamakazee: 這裏hot-fix分支被merge到master分支,QA直接在生產環境中測試。這是很差的方式,由於數據的不一致性可能致使問題
2.Copycat:這裏hot-fix被merge到master,而master分支自己被staged到一個專用的服務器。若是生產環境是基於pushes to the repository or a scheduled build來自動部署的,那麼
這就多是不可能的。
3.Paranoid:這裏hotfix分支staged on a dedicated server,QA必須評審測試,以後才能merge到master。那個staged server有可能須要replicate the data used in the production environment。可是若是因爲法律問題或者數據私密問題,也可能不可行。那麼一個可選項就是直接stage on the production itself.
一旦patch自己成功了,the hot-fix分支必須merge到stage,qa,develop分支上去。
$ git checkout master $ git merge --no-ff hot-fix/1234 $ git checkout stage $ git merge --no-ff hot-fix/1234 $ git checkout qa $ git merge --no-ff hot-fix/1234 $ git checkout develop $ git merge --no-ff hot-fix/1234
However, depending on the length of the milestones, it's possible that sufficient changes have been made in the pending release that the problem found in production has already been rectified, or the functionality surrounding the issue has been modified to a point where the problem no longer exists, or has been altered completely.
Finally, once the hot-fix has been applied to all the relevant branches it can now be removed.
$ git branch -d hot-fix/1234 $ git push origin :hot-fix/1234
If you find that there are numerous bugs in your production environment this can be attributed to insufficient details at the requirements stage of the project, or an inefficient QA process. Keep in mind that the QA process is only as good as the initial criteria, so validating the specification for a project is key to it's success.
It's also worth noting that any developer who creates a "temporary" branch should remain responsible for it, as they are the most likely candidates to know the status of the branch.