1目的

規範開發模式過程，指導項目研發、質控測試、DevOps的相關活動。

2適用範圍

本規範的作用範圍是為互聯網軟體產品相關項目開發模式的管理過程。

（1）   對項目團隊中研發人員在開發模式過程中的活動、職責等方面進行了指導；

（2）   對項目團隊中質控測試在開發模式過程中的活動、職責等方面進行了指導；

（3）   對項目團隊中DevOps人員在開發模式過程中的活動、職責等方面進行了指導。

3角色及職責定義

（1）   項目研發：需求功能的實現者，分支開發、轉測階段由研發負責人驅動，交付質控提測郵件中需明確六要素：

項目名稱、版本號、分支路徑、腳本路徑、部署手冊、功能邊界。

（2）   質控測試：為實現版本輪轉高效，除日常測試活動外，

測試環境【合併主幹併發布測試環境】、

預發佈環境【主幹測試通過發佈預發佈環境】、

生產環境【預發佈環境驗收通過，發佈生產環境並完成版本歸檔等】

由質控團隊統一負責服務。

（3）   DevOps：持續交付工具研發和維護，負責版本交付周期過程中的發佈支持。

4開發模式

包括單分支開發模式和多分支開發模式。下麵分別闡述每種開發模式在項目過程中如何進行。

4.1開發模式

（1）單分支開發模式：確定基線、拉分支、合主幹、項目發佈、版本歸檔、持續交付。

（2）多分支開發模式：確定基線、拉（特性）分支、同步/回滾/合主幹、項目發佈、

版本歸檔、持續交付。

4.1.1單分支開發模式

4.1.1.0確定基線版本

SVN-Trunk：工程Demo – 》特性開發–》 穩定版本

4.1.1.1拉分支

分支來源於穩定主幹，穩定主幹均需符合以下條件：

（1）   版本已發佈生產環境；

（2）   版本已完成版本歸檔。

4.1.1.2合主幹

分支提測合主幹

六要素：項目名稱、版本號、分支路徑、腳本路徑、部署手冊、功能邊界。

4.1.1.3項目發佈

4.1.1.3.1持續集成

• 隨著軟體項目複雜度的增加，對確保集成和軟體組件一起工作的要求也就越來越高，因此要早集成，常集成。早集成、常集成，有助於在早期發現項目風險和質量問題，若到項目後期才發現這些問題，解決問題的代價會很大，將導致項目延期或者項目失敗。

l  Jenkins是將代碼進行統一的編譯打包、還可以放到tomcat容器中進行發佈。

通過配置，將以前：編譯、打包、上傳、部署到Tomcat中的過程交由Jenkins，Jenkins通過給定的代碼地址URL，將代碼拉取到其“宿主伺服器”（就是Jenkins的安裝位置），進行編譯、打包和發佈到容器中。

在Jenkins的宿主伺服器中必須要有可以進行：代碼clone（Git）、代碼編譯（Maven）、代碼運行（Tomcat）的基本環境

4.1.1.3.2持續部署

Udeployer是一套完整的持續交付生態系統，在交付過程的每一個步驟都是可視化、自動化的，可以帶來包括效能在內的顯著的好處，自動應用部署也改進了軟體的總體質量。Udeployer集合了Jenkins、swarm、docker等工具，在跨網段、跨內外網等方面可以靈活配置。在整個版本交付生命周期（包括部署在內）推薦使用Udeployer，能夠把人為的干預最小化、節省各環節等待時間，使得交付的流程更清晰化。一旦把人的干預去掉，質量就更加可預測，會變得更好。

其他自動化部署工具（Ansible、SaltStack）

4.1.1.4版本歸檔

版本管理是為滿足不同需求，對同一產品或系統進行局部的改進和改型所產生的產品或系統系列的變更情況進行記錄、跟蹤、維護和控制的過程。

版本是記錄特定對象各個可選狀態的快照，版本管理的任務就是對對象的歷史演變過程進行記錄和維護，根據實際應用背景選擇合適的版本間的拓撲結構，並至少應包括以下功能：（1）新版本的生成;統一、協調管理各個版本；

（2）有效記錄不同版本的演變過程及對不同版本進行有效管理，以儘可能少的數據冗餘記錄各版本。

（3）保證不同版本在邏輯上的一致性和相對獨立性，一個版本的產生和消失不會對其

餘版本的內容產生影響。

（4） 版本切換時，指定了新的當前版本後，必須保證對象的映象和指定的版本保持一致。

4.1.1.5持續交付

4.1.1.5.1統一源碼路徑（保證測試環境、預發佈環境、生產環境的源碼一致性）

（1）分支：由歸檔後的主幹創建，操作人員為項目研發，用於新需求功能實現。

（2）主幹：由提測分支合併，操作人員為質控測試；用於功能測試、測試環境、預發佈環境、生產環境的運行。

（3）Tag：預發佈環境驗收通過，發佈生產環境並完成版本歸檔，操作人員質控測試，用於記錄生產環境穩定版本，便於回滾主幹操作。

4.1.1.5.2統一依賴關係（保證測試環境、預發佈環境、生產環境的容器一致性）

（1）  Swarm集群

l  Swarm是一套較為簡單的工具，用來管理docker集群，它將一群Docker宿主機變成一個單一的，虛擬的主機。Swarm使用標準的Docker API介面作為其前端訪問入口，換言之，各種形式的Docker Client(docker client in Go, docker_py, docker等)均可以直接與Swarm通信。

l  Swarm deamon只是一個調度器（Scheduler）加路由器(router)，Swarm自己不運行容器，它只是接受docker客戶端發送過來的請求，調度適合的節點來運行容器，這意味著，即使Swarm由於某些原因掛掉了，集群中的節點也會照常運行，當Swarm重新恢復運行之後，它會收集重建集群信息。下麵是Swarm的結構圖：

圖1

圖2

（2）  Docker倉庫

• Docker 是一個開源的應用容器引擎，讓開發者可以打包他們的應用以及依賴包到一個可移植的容器中，然後發佈到任何流行的 Linux 機器上，也可以實現虛擬化。容器是完全使用沙箱機制，相互之間不會有任何介面。

• 倉庫是集中存放鏡像文件的場所。有時候會把倉庫和倉庫註冊伺服器（Registry）混為一談，並不嚴格區分。實際上，倉庫註冊伺服器上往往存放著多個倉庫，每個倉庫中又包含了多個鏡像，每個鏡像有不同的標簽（tag）。

• 倉庫分為公開倉庫（Public）和私有倉庫（Private）兩種形式。

最大的公開倉庫是 Docker Hub，存放了數量龐大的鏡像供用戶下載。 其作為預設docker倉庫，但在國內下載速度很慢。當然，用戶也可以在本地網路內創建一個私有倉庫。當用戶創建了自己的鏡像之後就可以使用 push 命令將它上傳到公有或者私有倉庫，這樣下次在另外一臺機器上使用這個鏡像時候，只需要從倉庫上 pull 下來就可以了。

4.1.1.5.3自動化發佈（源碼交付和依賴關係交付，通過自動化交付實現）

同上“4.1.1.3項目發佈”

4.1.2多分支開發模式

同步/回滾/合主幹

4.1.2.1直接合併主幹

提測版本號末位-1與當前主幹版本號一致。

4.1.2.2先同步該主幹，再合併主幹

  （1）提測版本號末位-1與當前主幹版本號不一致；
（2）其他分支有歸檔記錄，找到最近一次歸檔的版本號。

4.1.2.3先回滾上一版本，再合併主幹

（1）提測版本號末位-1與當前主幹版本號不一致；

（2）其他分支無歸檔記錄；

（3）提測版本號末位-1在歷史版本中存在 ， 則需找到主幹版本號末位-1的主幹。

4.1.2.4先回滾分支對應主幹，再合併主幹

（1）提測版本號末位-1與當前主幹版本號不一致；
（2）其他分支無歸檔記錄；
（3）提測版本號末位-1在歷史版本中不存在，則需找到對應的拉分支時主幹。