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

時間 2019-11-29

標籤企業 svn 版本管理代碼上線方案欄目 SVN 简体版

原文原文鏈接

1.SVN服務實戰php

1) 什麼是SVN（Subversion）？css

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

2) svn與git的區別前端

svn集中式版本控制系統

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

svn版本控制系統工做流程以下：git

在中央庫上建立或從主幹複製一個分支
從中央庫check out 下這個分支的代碼
增長本身的代碼文件，修改現存的代碼或刪除代碼文件
commit代碼，假設有人在剛剛的分支上提交了代碼，你就會被提示代碼過時，你得先up你的代碼後再提交。up代碼的時候若是出現衝突，須要解決好衝突後再進行提交。

缺點：程序員

當沒法鏈接到中央版本庫的環境下，你沒法提交代碼，將代碼加入版本控制；你沒法查看代碼的歷史版本以及版本的變化過程。提交到版本控制系統中的代碼咱們都默認經過自測可運行的，若是某個模塊的代碼比較複雜，不能短期內實現爲可測試的功能，那麼你須要等很長的時間才能提交本身的代碼，因爲代碼庫集中管理，所以，須要對中央版本庫的存儲作備份。這點分佈式的版本控制系統要好一些。Svn的備份要備份全部代碼數據以及全部更改的版本記錄。web

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庫。apache

運維人員掌握版本管理vim

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

安裝，部署，維護，排障。
簡單使用，不少公司都是由開發來管理，包括創建新倉庫和添加刪除帳號
對於版本控制系統，運維人員至關於開發商，開發人員是業主，運維搭建的系統爲開發人員服務的。

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%以上的故障是和開發程序代碼有關的，（好比：開發寫錯了一個循環代碼，致使了死循環，此時大量用戶訪問這個程序，就能把服務器資源耗盡，搞死服務器）

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

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

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

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

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

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

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

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

本地開發人員從SVN中取代碼。當天上線的提交到trunk，不然，長期項目單開分支開發，而後在合併主線（trunk）
辦公內網開發測試時，由開發人員或配置管理員經過部署平臺jenkins實現統一部署，（即在部署平臺上控制開發機器從SVN取代碼，編譯，打包，發佈到開發機器，包名如idc_dep.war）
開發人員通知或和測試人員一塊兒測試程序，沒有問題後，打上新的tag標記。
配置管理員，根據上步的tag標記，checkout出上線代碼，並配置好IDC測試環境的全部配置，執行編譯，打包（mvn，ant）（php不須要），而後發佈到IDC內的統一分發服務器，這裏要注意，不一樣環境的配置文件是隨代碼同時發佈的。
配置管理員或SA上線人員，把分發的程序代碼內容推送到相關測試服務器（包名如idc_test.war）,而後通知開發及測試人員進行測試。若是有問題向上回退，繼續修改。
若是測試沒有問題，繼續打好tag標記，此時，配置管理員，根據上步的tag標記，checkout出測試好的代碼，並配置好IDC正式環境的全部配置，執行編譯，打包（mvn，ant）（php不須要），而後發佈到IDC內的統一分發服務器主機，準備批量發佈。
配置管理員或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管理界面（界面底層調用相關腳本實現分發推送代碼以及重啓服務器），而後普通的初級上線人員就能夠在平臺裏實現僅僅點鼠標，敲回車，就能實現平滑上線和平滑回滾代碼了，固然，自動化和完善的程度也許沒咱們說的這麼好，可是，思路是這樣的。