企業SVN版本管理與代碼上線方案

 

1.SVN服務實戰

1) 什么是SVN（Subversion）？

• Svn（subversion）是近年來崛起的非常優秀的版本管理工具，與CVS管理工具一樣，SVN是一個跨平台的開源的版本控制系統。Svn版本管理工具管理着隨時間改變的各種數據。這些數據放置在一個中央資料檔案庫（repository）中，這個檔案庫很像一個普通的文件服務器或者FTP服務器，但是，與其他服務器不同的是，SVN會備份並記錄每個文件每一次的修改更新變動。這樣我們就可以把任意一個時間點的檔案恢復到想要的某一個舊的版本，當然也可以直接瀏覽指定文件的更新歷史記錄。
• 為什么會有svn這樣一個項目？
• 官方解釋：為了接管CVS的用戶基礎，確切的說，我們寫了一個新的版本控制系統，它和CVS很相似，但是它修正了以前CVS所沒有解決的許多問題。問題見SVN官方首頁。
• SVN是一個非常通用的軟件系統，它常被用來管理程序源碼，但是它也可以管理任何類型的文件，如文本，視頻，圖片等等。

2) svn與git的區別

svn集中式版本控制系統

svn版本控制系統是集中式的數據管理，存在一個中央版本庫，所有開發人員本地開發所使用的代碼都是來自於這個版本庫，提交代碼也都必須提交到這個中央版本庫。

svn版本控制系統工作流程如下：

1. 在中央庫上創建或從主干復制一個分支
2. 從中央庫check out 下這個分支的代碼
3. 增加自己的代碼文件，修改現存的代碼或刪除代碼文件
4. commit代碼，假設有人在剛剛的分支上提交了代碼，你就會被提示代碼過期，你得先up你的代碼后再提交。up代碼的時候如果出現沖突，需要解決好沖突后再進行提交。

缺點：

當無法連接到中央版本庫的環境下，你無法提交代碼，將代碼加入版本控制； 你無法查看代碼的歷史版本以及版本的變化過程。提交到版本控制系統中的代碼我們都默認通過自測可運行的，如果某個模塊的代碼比較復雜，不能短時間內實現為可測試的功能，那么你需要等很長的時間才能提交自己的代碼，由於代碼庫集中管理，因此，需要對中央版本庫的存儲做備份。這點分布式的版本控制系統要好一些。Svn的備份要備份所有代碼數據以及所有更改的版本記錄。

git分布式的版本控制

• git是由Linus開發的，所以很自然的git和Linux文件系統結合的比較緊密，以至於在windows上你必須使用cygwin才能使其完美的工作。
• 那git憑啥叫做分布式的版本控制系統呢？還是從其工作模式講起。
• git中沒有了中央版本庫的說法了，但是為了開發小組的代碼共享，我們通常還是會搭建一個遠程的git倉庫。
• 但是和svn不同的是，開發者本地也包含了一個完整的git倉庫，從某種程度上說本地的倉庫和遠程的倉庫在身份上是等價的，沒有主從之分。
• 如果你的項目是閉源項目，或者你習慣於以往的集中式的管理模式的話，那么在git下你也可以像svn那樣的工作，只是流程中可能會增加一些步驟。

• 你本地創建一個git庫，並將其add到遠程git庫中。
• 你在本地添加或者刪除文件，然后commit，當然commit操作都是提交到本地的git庫中了。（嗯，其實是提交到git目錄下的objects目錄中去了）
• 將本地git庫的分支push到遠程git庫的分支，如果這個時候遠程git庫中已經有別人push過，那么遠程git庫將不允許你push，這時候你需要先pull，然后如果有沖突，處理好沖突，commit到本地git庫后，再push到遠程git庫。

從上面的描述我們可以看到，我們每個開發人員的本地都會有一個git庫，我們可以隨時進行commit而不需要聯網，可以隨時查看歷史版本，當某一個功能點開發完了之后我們可以將commit后的內容push到遠程git庫了，如果遠程git庫的版本在你上次clone或者pull之后變化了，那么你需要進行pull並處理沖突，提交之后，再push到遠程git庫。

運維人員掌握版本管理

對於版本管理系統，運維人員需要掌握的技術點：

1. 安裝，部署，維護，排障。
2. 簡單使用，很多公司都是由開發來管理，包括建立新倉庫和添加刪除賬號
3. 對於版本控制系統，運維人員相當於開發商，開發人員是業主，運維搭建的系統為開發人員服務的。

3)SVN服務端運行方式

svn服務常見的運行訪問方式有3種：

（1）獨立服務器訪問

訪問地址如：svn：//svn.yunjisuan.org/sadoc;

（2）借助apache等http服務

訪問地址如：http://svn.yunjisuan.com/sadoc;

a,單獨安裝apache+svn（不要用） b,CSVN（apache+svn）是一個單獨的整合的軟件，帶web界面管理的SVN軟件

（3）本地直接訪問（例如：file://application/svndata/sadoc）

2.搭建SVN服務端

yum -y install subversion

mkdir -p /application/svndata   #數據存儲根目錄
創建一個新的Subversion項目test，其實，類似yunjisuan這樣的項目可以創建多個，每個項目對應不同的代碼，這里只是以創建一個項目為例演示：

svnadmin create /application/svndata/test

tree /application/svndata/test  查看項目目錄結構

cd /application/svndata/test/conf/

 cp svnserve.conf{,.bak}

vim svnserve.conf  修改配置文件

anon-access = none          #禁止匿名訪問
auth-access = write         #驗證訪問可寫
password-db = passwd #密碼文件位置
authz-db = authz     #驗證文件位置
此配置文件里的每條配置代碼必須頂格寫，不能有空格。

啟動svn服務

svnserve -d -r /application/svndata/    啟動服務
netstat -antup | grep 3690                  查看服務
vim   /application/svndata/test/conf/passwd
test= 123123      #設置賬號密碼
yst     = 123123      #設置賬號密碼

權限配置說明
#用戶組格式：
【groups】
=，
其中，1個用戶組可以包含1個或多個用過戶，用戶間以逗號分隔。
例如：harry\_and\_sally = harry,sally     #==>用戶組 = 用戶1，用戶2

#版本庫目錄格式：
[<版本庫>：/項目/目錄]  #例如：[repository:/baz/fuz]
@<用戶組名> = <權限>    #例如：@harry\_and\_sally = rw
<用戶名> = <權限>       #例如：harry = rw
#其中，方框號內部分可以有多種寫法：
[/],表示根目錄及以下，根目錄是svnserve啟動時指定的，我們指定為/application/svndata，[/]就是表示對全部版本庫設置權限。
[repos:/]，表示對版本庫repos設置權限。
[repos:/yunjisuan]，表示對版本庫repos中的yunjisuan項目設置權限。
[repos:/yunjisuan/benet]，表示對版本庫repos中的yunjisuan項目的benet目錄設置權限。
#權限主體可以是用戶組，用戶或*，用戶組在前面加@，*表示全部用戶。
#權限可以是w，r，wr和空，空表示沒有任何權限。
#authz中每個參數都要頂格寫，開頭不能有空格。
#對於組，要以@開頭，用戶不需要@開頭。

vim  /application/svndata/test/conf/authz

[groups]
yun= test,yst         #新增本行，定義組名
[test:/]                   #定義授權的范圍
yunjisuan = rw                  #用戶單獨授權
benet = r                       #用戶單獨授權
@sagroup = r                    #組用戶授權

重啟動svnserve

3.搭建SVN客戶端

使用svn客戶端（windows版）

推薦：TortoiseSVN-1.9.7.27907-x64-svn-1.9.7

一路  下一步，安裝成功

先在本地創建一個目錄，起名任意，比如data

選擇右鍵菜單里的SVN Checkout，輸入svn地址， 本例為svn://192.168.1.11/test

點ok,輸入前面創建的用戶名和密碼test,123123，從版本庫中取得代碼

在本地修改，后要提交到版本庫，右鍵點commit,提交生成第一版本，其他程序員修改會生成不同版本，我們本地要下載代碼，右鍵點 update,下載最新的代碼版本

4.SVN鈎子腳本

1)常用鈎子腳本

post-commit:在提交完成成功創建版本之后執行該鈎子，提交已經完成，不可更改，因此，本腳本的返回值被忽略。提交完成時觸發事務

pre-commit提交完成前觸發執行該腳本

start-commit在客戶端還沒有向服務器提交數據之前，即還沒有建立Subversion transaction之前，執行該腳本（提交前出發事務）

利用鈎子腳本觸發同步數據的注意事項

（1）一定要定義變量，主要是用過的命令的路徑。因為SVN的考慮的安全問題，沒有調用系統變量，如果手動執行是沒有問題，但SVN自動執行就會無法執行了。

（2）SVN的同步目錄在 update之前一定要先checkout一份出來，還有這里一定要添加用戶和密碼。

（3）加上了對前一個命令的判斷，如果update的時候出了問題，程序沒有退出的話還會繼續同步代碼到Web服務器上，這樣會造成代碼有問題。

（4）建議最好記錄日志，出錯的時候可以很快的排錯

（5）最后是數據同步，rsync的相關參數一定要清楚。

 svn鈎子生產應用場景舉例

• pre-commit:限制上傳文件擴展名及大小，控制提交要輸入的信息等。
• post-commit:SVN更新自動周知，MSN，郵件或短信周知。 SVN更新觸發checkout程序，然后實時rsync推送到服務器等。

 2)svn鈎子生產應用實戰

rsync與svn鈎子結合實現數據實時同步某企業小案例

（1）建立同步WEB目錄

mkdir -p /data/www

（2）將SVN中內容checkout到WEB目錄一份。

svn checkout svn://192.168.1.13/test  /data/www --username=test  --password=123123
3）制作鈎子腳本，post-commit

root@localhost yunjisuan]# cd /application/svndata/test/hooks/ [root@localhost hooks]# cp post-commit.tmpl post-commit #復制模板一份 [root@localhost hooks]# egrep -v "#|^$" post-commit #模板原始內容 REPOS="$1" REV="$2" mailer.py commit "$REPOS" "$REV" /path/to/mailer.conf [root@localhost hooks]# vim post-commit #修改post-commit腳本 [root@localhost hooks]# egrep -v "#|^$" post-commit REPOS="$1" #傳參（未用上） REV="$2" #傳參（未用上） SvnIP="192.168.1.13" #svn服務端的IP地址 ProjectName="test" #svn服務端的項目庫名稱 UserName="test" #賬戶姓名 PassWord="123123" #賬戶密碼 LocalPath="/data/www" #位於svn本地的共享目錄 SVN=/usr/bin/svn #svn命令的絕對路徑 export LC_CTYPE="en_US.UTF-8" #中文字符集支持 export LC_ALL= if [ ! -d ${LocalPath} ];then mkdir -p ${LocalPath} $SVN checkout svn://${SvnIP}/${ProjectName} ${LocalPath} --username=${UserName} --password=${PassWord} #新創建目錄需要先經過checkout才能update else $SVN update --username $UserName --password $PassWord /data/www #更新共享目錄內容 fi if [ $? -eq 0 ];then /usr/bin/rsync -az --delete /data/www /tmp/ #數據同步推送到本地/tmp目錄下（生產環境可以直接同步推送到Web測試服務器） fi

chmod 700 post-commit  

特別提示：
當用戶通過svn更新鈎子post-commit所在的項目庫時，在更新完畢之后會自動觸發鈎子腳本

模擬更新項目庫版本

在windows系統中的data目錄中添加代碼文件，然后右鍵點commit，成功后觸發鈎子腳本

 ll /tmp/www/                    #推送后的數據目錄

顯示全部提交后的代碼文件

綜上，post-commit鈎子腳本測試成功。

5.大中小型企業上線解決方案

1）小型公司代碼上線案例（十幾台服務器）

開發每次修改完代碼就直接提交，然后通過FTP直接更新到Web服務器網頁目錄；沒有專門的測試人員，完全是由用戶來進行測試體驗。

小型公司一般只有幾個開發人員，網站核心程序大多數都是PHP語言開發，為了方便，會直接通過FTP直接上傳程序代碼到線上服務器，隨時隨地上線更新。

• 開發人員發布的代碼不經過測試人員的測試，且用戶訪問頁面刷新后頁面即改變，也可能刷新瞬間程序在更新，到時無法訪問，對網站用戶的體驗比較差，如果開發寫錯了代碼，造成的影響就更大了，這是拿用戶作為測試的上線方案。
• 據統計，網站中大概50%以上的故障是和開發程序代碼有關的，（比如：開發寫錯了一個循環代碼，導致了死循環，此時大量用戶訪問這個程序，就能把服務器資源耗盡，搞死服務器）

小型企業上線架構方案建議：

1. 開發人員需在個人電腦搭建LAMP環境測試開發好的網站代碼，並且在辦公室或IDC機房的測試環境測試通過，最好有專職測試人員。
2. 程序代碼上線規定時間，例如，三天上線一次，如網站需經常更新可每天下午17點上線，這個看網站業務性質而定，原則就是影響用戶體驗最小。
3. 代碼上線之前需備份，網站程序出了問題方便回退，另外，網站程序出了問題方便回退，另外，從上線技巧上講，上傳代碼時盡可能先傳到服務器網站臨時目錄，傳完整后一步mv過去，或者通過ln做軟連接。（線上更新代碼思路）
4. 務必由運維人員管理上線，對於代碼的功能性，開發人員更在意，而對於代碼的性能和服務的穩定，運維更在意，因此，如果網站問題歸運維管，就要讓運維上線這樣更規范科學。否則，開發隨意更新，出了問題運維負責，這樣就錯了。

2）中型企業上線解決方案

中型企業上線，一般是規范運維人員操作步驟，制定統一的上線操作腳本，備份文件名稱，備份文件路徑。使操作人性化，統一化，自動化。

3）大型企業上線解決方案

大型企業上線一般制度和流程控制較多，比較嚴謹，下面是某大型企業上線解決方案架構：

SVN里的內容：
1，程序代碼
2，服務的配置
3，項目文檔，設計文檔，運維部署優化文檔

門戶大型網站架構環境代碼上線具體方案：

1. 本地開發人員從SVN中取代碼。當天上線的提交到trunk，否則，長期項目單開分支開發，然后在合並主線（trunk）
2. 辦公內網開發測試時，由開發人員或配置管理員通過部署平台jenkins實現統一部署，（即在部署平台上控制開發機器從SVN取代碼，編譯，打包，發布到開發機器，包名如idc_dep.war）
3. 開發人員通知或和測試人員一起測試程序，沒有問題后，打上新的tag標記。
4. 配置管理員，根據上步的tag標記，checkout出上線代碼，並配置好IDC測試環境的所有配置，執行編譯，打包（mvn，ant）（php不需要），然后發布到IDC內的統一分發服務器，這里要注意，不同環境的配置文件是隨代碼同時發布的。
5. 配置管理員或SA上線人員，把分發的程序代碼內容推送到相關測試服務器（包名如idc_test.war）,然后通知開發及測試人員進行測試。如果有問題向上回退，繼續修改。
6. 如果測試沒有問題，繼續打好tag標記，此時，配置管理員，根據上步的tag標記，checkout出測試好的代碼，並配置好IDC正式環境的所有配置，執行編譯，打包（mvn，ant）（php不需要），然后發布到IDC內的統一分發服務器主機，准備批量發布。
7. 配置管理員或SA上線人員，把分發的內容推送到相關正式服務器（包名如idc_product.war），然后通知開發及測試人員進行測試。如果有問題直接發布回滾指令。

IDC正式上線的過程對於JAVA程序，可以是AB分組上線的思路，即平滑下線一半的服務器，然后發布更新代碼測試，無問題后，掛上服務器，同時在平滑下線另一半的服務器，然后發布更新代碼測試（或者直接發布后就掛上線）

PHP程序代碼上線的具體方案：

對於PHP上線方法：發布代碼時（也需要測試流程）可以直接發布到正式線臨時目錄，然后mv或更改link的方式發布到正式線目錄，不需要重啟http服務。這是sina，ganji的上線方案。

JAVA程序代碼上線的具體方案：

對於java上線方法：較大公司需要分組平滑上線，例如，首先從負載均衡器上摘掉一半的服務器，發布代碼后，重啟服務器測試，沒問題后，掛上經過測試的這一半，再下另外一半。如果前端有DNS智能解析，上線還可以分地區上線若干服務器，逐漸普及到全國的服務器，這個被稱為灰度發布。

和訊案例

ABCD 12:33:24 我們這里代碼發布都不太標准，全部都是開發自己搞 12：35：14 目前是什么個方式呢 說下現狀即可。 ABCD 12:36:04 就是很傳統，開發有權限可以上機器，我們就把應用部署好，他們隨便折騰。 ABCD 12:41:05 源代碼是svn，靜態內容都是同步分發

（3）小米案例

XYZ 13:36:49 代碼上線都是開發上，我們運維這邊沒有流程...如果代碼發布導致了問題，就是開發的問題。 XYZ 13:37:55 服務器上面有一個客戶端，開發自己在頁面上點發布，客戶端就去拉代碼了。 就是這么個額流程，就像你以前說的，項目責任制，誰的項目出問題了。找開發和運維 13:49:08 不需要重啟服務器么？還有直接拉到站點目錄么？ XYZ 13:49:17 嗯，都是自動的 他們有個管理系統 13:49:49 如何保證不影響用戶呢？ 還有怎么回滾的。 XYZ 13:50:12 還沒有做到這點把 那個管理系統可以回滾的，好像 平時把客戶的部署上去，再把機器加入到那個系統中 他們就可以發了。 XYZ 13:58:16 運維這邊就管添加機器和安裝客戶端，也有發布權限，項目上線后很少發。一教就會沒有在這塊搞過太多，那個程序和版本管理結合的。實現原理應該就是客戶端收到服務器發來的clone命令和路徑，就去執行了。

什么是配置管理員呢？

就是在開發和運維中間起一個連接紐帶的一個職位，這個職位一般在大公司里會設置，負責SVN的管理，上線管理，申請，協調等工作。

自動化部署和上線代碼管理

對於門戶網站或重視規范或開發能力較強的公司也許會結合系統服務和WEB界面管理來更科學更自動的進行上線代碼管理，如開發一個自動化代碼上線部署平台，其實就是一個web管理界面（界面底層調用相關腳本實現分發推送代碼以及重啟服務器），然后普通的初級上線人員就可以在平台里實現僅僅點鼠標，敲回車，就能實現平滑上線和平滑回滾代碼了，當然，自動化和完善的程度也許沒我們說的這么好，但是，思路是這樣的。