工具選擇

程式碼管理用什麼工具好，有人喜歡git,不過git有個小小的缺點，就是對UI使用的大檔案支援不太好，比如PSD文件，PNG文件等等。

作為windows下的佛系程式設計師，我還是保守一點，團隊使用SVN。

如果有兩個工具都差不多，選擇最適合你的那個，或者說，選擇團隊裡面會的人最多的那個。

為什麼，節省時間成本。

這並不是說不能使用git和github, 該用你還是用。

只是在團隊中我們首選了svn, 方便大檔案的儲存。

工具選擇哪個，主要還是看整個團隊。

搭建環境

伺服器端我們使用visualsvn server.

開源免費，然後許可權控制挺棒的。

有錢的話可以購買一臺騰訊的windows雲伺服器，放在外網部署。

如果擔心程式碼安全問題，可以購買一臺本地機器，然後把IP對映出去。

人多的團隊可能擔心SVN的拉程式碼慢的問題，對於以前做手機的MTK團隊的確需要擔心一下，動不動1-2G的程式碼。

對JAVA web團隊，這個不用太擔心，除非你的網路非常差，那得考慮讓老闆加下頻寬了。

如果老闆不願意，你可以算一下拉程式碼等待的時間X每個人的小時工資。

絕對大於頻寬的錢。

作為網際網路開發團隊，有兩樣錢不能省，一個是開發機的配置，一個就是網路頻寬。

太慢不光影響效率，還影響開發心情。

資料夾規劃

在我們團隊中的經驗是拆分為3個大的倉庫，一個程式碼，一個文件，一個釋出。
也就是code,doc

code我們需要建立分支，以便在釋出和開發子功能的時候拉取分支。

其它的比如人力資源行政(hr)，運維(devops)也拆分出來成為獨立的倉庫。

程式碼(code):

下面用來存放各個專案的程式碼，按專案名稱進行劃分。
比如你有一個oa專案，有一個user專案(使用者中心).
我們可以這樣子進行存放。
oa
user

資料夾中看專案拆分程度，進行子專案的命名。

1.user是一個整體專案，沒有做前後端分離,只有一個web專案。
我們可以寫成
user-web。
2.oa是一個前後端分離的專案，分為PC，手機兩個前端專案，一個api專案。
那我們可以寫成
oa-api
oa-web-pc
oa-web-mb

文件(doc):

文件也是按照專案進行劃分。
之所以文件單獨分離，主要還是許可權控制的問題，程式碼一般不能被產品和UI拿到的，但是文件是大家都要看的，分離以後許可權控制相對簡單一點

。
還是假設有兩個專案oa和user.
oa下面有
task(各種需求和任務，為什麼用task,這個單詞好記，簡單)
ui(原型和ui設計就放這個裡面了)
test(各種測試用例和測試報告就放這裡面了)
lab(專案的衍生品做各種小實驗的小工程文件，都可以丟這個裡面)

user下面呢，同樣是這些資料夾

hr和devops

hr和devops就不用太介紹了，大家自己想怎麼放就怎麼放

devops裡面有一個要介紹的
需要有一個專案規劃表
比如oa-api 用什麼埠，放哪臺伺服器

版本釋出

RC版本釋出

RC版本釋出就是從主幹上拉取測試過的程式碼，建立一個分支，進行釋出。

拿oa為例，我們可以建立分支 rc-oa-1.00.0106 表示是1.00版本，2018年1月6號釋出的。

正式版本釋出

正式版本就不用特別拉取分支了，因為我們RC上線，測試通過了，就是直接釋出到正式了。

個別公司還有uat環境，但是對於小公司單應用快速迭代，RC已經夠用了。

就算是uat環境，也是直接拉取rc, 只是配置的啟動引數不一樣。

子功能新增

一般小的模組，可以直接在主幹上進行開發，這沒有太大的問題。

如果有影響很大的模組，建議建立一個分支 task-xxxx-oa-1.00.0106 這個樣子。

在分支上開發完成以後，再通過打patch包合併到我們的主幹上來。

迭代週期

一般每一週，每個人保持2-3個功能的開發上線，是比較合理的。

大的功能點耗費的時間長一點，這個時候可以考慮建立分支。

我們一般週三下午就準備RC上線，週四RC測試一天，週四下午發正式伺服器。

週五規劃好下週功能，並討論需求。

自動化釋出

每天下午四點會自動化釋出一個版本給測試進行迴歸.
保證出現重大問題的及時回退。