SVN多分支開發模式V1.0.1

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）新版本的生成;統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在歷史版本中不存在，則需找到對應的拉分支時主幹。