成熟的Web開發團隊開發、測試、上線的環境和流程是怎樣的？

團隊現有的開發環境無法滿足開發人員快速開發、調試、聯調的需求，測試環境無法較好地模擬線上環境，依賴於人工操作的上線難以保證正確性且不易維護……因此目前需要設計一套合理的開發流程來滿足前端、後端的開發需求。

想借鑒一下目前成熟團隊使用的環境和流程是怎樣的，如何解決這些問題？

p.s. 之前找到一份《一淘前端工作環境簡介》： http://www.slideshare.net/neekey/2-12059408

---

1年前的問題，阿大的ppt還是12年的。。。現在我幫你回答一下吧。

先簡單說下你貼的一淘那個工作環境，由於之前我也在taobao干過，知道那個daily的作用，簡單說下，其實就是一套模擬的線上測試環境，包括數據，是上線前測試的最後一關，當然上daily還是需要在測試環境全測好才上的，那是最後一道關卡。

環境和流程，你貼的ppt是一種方法，細節涉及了很多，比如git和svn的操作，高級特性的使用之類。期間還介紹了一些打包的流程，目錄管理的規範，命名規則之類，個人感覺不存在通用性。至少在你現在的項目中沒有什麼實際的借鑒價值。

現在來回答你的問題。

總結一下：

1，你需要一個可以模擬線上的開發環境。

2，你需要一個可以模擬線上的測試環境。

3，你需要一個可連調的測試環境。

4，你需要一個自動化的上線系統。

5，一個開發流程適合前後端的。

1，本地反向代理線上真實環境開發即可。（apache，nginx，nodejs均可實現）

2，模擬線上的測試環境，其實就是你需要一台有真實數據的測試機么，我建議沒條件搭daily的，就直接用線上數據測好了，只不過程序部分走你們的測試環境而已，有條件搭daily當然最好咯。

3，可連調的測試環境，分為2種。一種是你們開發測試都在一個區域網段，直接綁hosts就完了，不在一個網段，就一人給一台虛擬的測試機，放在大家都可以訪問到的公司內網，代碼直接往上布即可。

4，自動化的上線系統，如果你們運維不給你們做，我猜你們都是直接ftp往線上扔？那麼你可以自己做一個簡易的上線系統。原理不複雜，每次上線時都抽取最新的trunk或master，做一個tag，再打一個時間戳的標記，然後分發到cdn就行了。界面里就2個功能，打tag，回滾到某tag，部署【夠簡易了吧，而且是全自動的】。

5，開發流程就是看項目了還有所用到的工具，構建，框架了。簡單來說，原則就是分散獨立開發，互相不干擾，連調時有hosts可綁即可。

回答了你的問題之後，我說下我自己的項目是怎麼個開發流程。

灰常簡單，代碼管理工具是svn，起新需求就起新分支，獨立開發，開發完合併到trunk，trunk不做任何開發工作，只負責merge。

上線有上線系統，你可以理解為我上面說的那個簡易功能的加強版。我們是自帶build的功能的。

自己編寫build腳本，ant，grunt隨便了。做好連到發布系統，一鍵集成，本地只關心源碼開發。

本地環境，我拿nodejs寫了一個自帶rewrite，反向代理的server，超級模擬線上，一個hosts組管理的工具，一套適合自己部門的grunt插件庫【就是很多很多grunt插件。。】。完全適合開發各種獨立項目了。

當然如果你的測試，文檔都集成在build那一步，是最棒的了。

協同合作我們是每個人開發都有一台自己的測試機，linux的，我本地也有工具可以完成自動build+push的功能。方便快捷。

可能全看下來挺複雜，不過前端工程化確實就是這個樣子。幫你脫離之前的手忙腳亂，專註於業務的開發。

各位大神輕噴。我只是分享自己的經驗。。

---

先上圖

如果看懂了的話就不用看下面說明了。。。

---------------------

# 背景

這個項目剛到v0.5，只上了幾次線了。遠不是成熟項目，只能作為參考。估計後續還得改。歡迎大家提建議~

項目是 Java Spring MVC項目。前台端代碼在一個項目里。版本管理採用maven + git（stash），任務管理用JIRA，文檔管理用Confluence。發布系統是公司內部的發布系統，而不是Bamboo。

# 幾個概念

## ops

最中間的那個大方框。ops系統，公司運維做的，是用來發布項目的。從git庫中拷出代碼相應的branch，根據maven的profile 編譯代碼，測試，部署可執行文件到server上，重啟應用。

ops有兩個系統，線上和線下。就是大框裡面的兩個小框。有office的是辦公室發布系統（線下）的。

automan-xxx 就是對應不同的部署應用。因為branch，profile和server不一樣，不同的應用有不同的功能。大致功能是：

* 線下開發 automan-dev

* 線上開發 automan-dev

* 線上測試 automan-alpha

* 線上測試 automan-beta

* 線上運營 automan

* 個人調試 automanXXXX

下面是branch，profile，server的含義。

## branch

git的分支。可以理解成 按用途歸類的版本集合。

### 各分支的功能

* master 用於線上發布

* feature-xxx 用於添加功能，添加完刪除

* develop 用於合併feature分支。

* release 用於發布前的測試，發布完刪除

* bugfix-xxx 用於修復develop和master分支的bug。

### 各分支的關係和流程圖

## profile

profile是maven的參數。maven根據不同的profile，選擇不同的編譯配置，從而編譯出不同配置的可執行文件。

### 不同profile的不同用途和編譯配置

| 名稱 | 用途資料庫 | 外部環境 |

| -----------| ----------------------------------------------| -----------|

| offline | 線下和本機測試線下，開發資料庫 | 線下 |

| develop | 線上develop分支測試線下，開發資料庫 | 線上 |

| alpha | 線上alpha測試線下，測試資料庫 | 線上 |

| online | 線上beta測試和線上環境線上，產品資料庫 | 線上 |

## server

運用部署的主機，分線上和線下兩套主機。線上主機又分線上測試和線上產品主機。線上測試按不同用途有三組主機：develop，alpha和beta。

因為我們項目沒有綁定域名，所以不需要修改host。直接訪問對應主機的ip或者域名+埠就可以了。

# 流程

主要流程有三個：添加新功能，修復Bug和發布新版本。

## 添加新功能

1. 發 新功能或改進 類型問題 到 JIRA 比如 ATM-54 重新設計API介面 已解決
2. 把問題分配給自己（修復「經辦人」）
3. 根據問題的代碼（上面功能的代碼為ATM-54）從develop檢出本地功能分支。比如 feature/ATM-54 或者 簡寫 ATM-54
4. 添加功能
5. 在本地測試通過
6. 提交到本地庫。commit message以 功能的代碼（比如ATM-54）開頭。比如「ATM-54 重新設計API介面」
7. push分支到遠程
8. 搭建線下測試環境（已有測試環境只需要修改branch）
9. 測試功能。如果有bug，修改代碼，跳到5。
10. 搭建線上測試環境（已有測試環境只需要修改branch）
11. 在線上develop環境測試通過
12. 提交pull請求
13. 找人 review代碼並merge到develop和master。

## 修復Bug

1. 發 bug類型問題 到 JIRA 比如 ATM-57 版本太多顯示不全
2. 把問題分配給自己（修改「經辦人」）
3. 根據問題的代碼（比如上面問題的代碼為ATM-57）從master檢出本地Bug修復分支。比如 bugfix-ATM-57 或者 簡寫 ATM-57
4. 修復bug
5. 在本地測試通過
6. 提交到本地庫。commit message以 問題的代碼（比如 ATM-57） 開頭。比如"ATM-57 修復 版本太多顯示不全"
7. push分支到遠程
8. 在線下環境測試通過（小問題可省略）
9. 在線上develop環境測試通過
10. 提交pull請求
11. 找人 review代碼並merge到develop和master。

## 發布新版本

1. 給develop添加tag：v+版本號+a
2. 從develop檢出release_latest
3. 在ops中部署 automan-alpha
4. 線上alpha測試
5. 如有bug，按照 修復bug流程 修復，並merge到release_latest。重新部署。
6. 給release添加tag：v+版本號+b
7. 在ops中部署 automan-beta
8. 線上beta測試
9. 如有bug，按照 修復bug流程 修復，並merge到release_latest。重新部署。
10. 給release添加tag：v+版本號
11. merge到master。
12. 在ops中部署 automan

---

就用atlassian 那一套不好嗎？

Jira 拿來管理 事件 的， 還有設置Agile 項目管理的。

Git 和 Stash 拿來 code review 和管理 branch 的， 所有的branch 都按照Jira 的事件編號來命名

Bamboo 是做 auto-build 的，一旦 stash 提交了pull request， 然後review 通過了， merge 了，自動build，build的過程中可以增加測試。 Mock 的unit test, selenium 這種integrated 也行。每次build 自動運行 （實際上， pull request 的時候就會運行）

Confluence 用來寫文檔，記錄工作會議，寫wiki 的。

這一套不是挺好的嗎？manager 就負責寫 confluence 和 盯著 agile 來督促 各模塊 （dev，QA， staging， production）就好了；QA負責寫一點 unit test和selenium， 或者給大家買飯盒也行；剩下的程序員 就狂寫代碼，狂提交啊。

---

可以研究下百度出的前端解決方案 Fis

---

學到老

---

推薦閱讀：