JAVA團隊開發手冊 - 2.代碼管理

工具選擇

代碼管理用什麼工具好，有人喜歡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測試一天，週四下午發正式服務器。

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

自動化發佈

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