1.SVN服務實戰 1) 什麼是SVN(Subversion)? Svn(subversion)是近年來崛起的非常優秀的版本管理工具,與CVS管理工具一樣,SVN是一個跨平臺的開源的版本控制系統。Svn版本管理工具管理著隨時間改變的各種數據。這些數據放置在一個中央資料檔案庫(repository)中 ...
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版本控制系統工作流程如下:
- 在中央庫上創建或從主幹複製一個分支
- 從中央庫check out 下這個分支的代碼
- 增加自己的代碼文件,修改現存的代碼或刪除代碼文件
- 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庫。
運維人員掌握版本管理
對於版本管理系統,運維人員需要掌握的技術點:
- 安裝,部署,維護,排障。
- 簡單使用,很多公司都是由開發來管理,包括建立新倉庫和添加刪除賬號
- 對於版本控制系統,運維人員相當於開發商,開發人員是業主,運維搭建的系統為開發人員服務的。
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 #設置賬號密碼
許可權配置說明
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管理界面(界面底層調用相關腳本實現分發推送代碼以及重啟伺服器),然後普通的初級上線人員就可以在平臺里實現僅僅點滑鼠,敲回車,就能實現平滑上線和平滑回滾代碼了,當然,自動化和完善的程度也許沒我們說的這麼好,但是,思路是這樣的。