連接:https://pan.baidu.com/s/1A3Iq3gGkGS27L_Gt37_I0g
提取碼:ncy2
複製這段內容後打開百度網盤手機App,操做更方便哦php
- Svn版本管理工具管理着隨時間改變的各類數據。這些數據放置在一箇中央資料檔案庫(repository)中,這個檔案庫很像一個普通的文件服務器或者FTP服務器,可是,與其餘服務器不一樣的是,SVN會備份並記錄每一個文件每一次的修改更新變更。這樣咱們就能夠把任意一個時間點的檔案恢復到想要的某一箇舊的版本,固然也能夠直接瀏覽指定文件的更新歷史記錄
- SVN是一個很是通用的軟件系統,它常被用來管理程序源碼,可是它也能夠管理任何類型的文件,如文本,視頻,圖片等等
Subversion官網:
http://subversion.tigris.org/
http://subversion.apache.org/
svn客戶端:http://toroisesvn.net/
svn中文網站:http://www.iusesvn.com/
中文常見問題解答FAQ:http://subversion.apache.org/faq.zh.html
官方手冊:http://svnbook.red-bean.com/ 中英都有html
svn版本控制系統是集中式的數據管理,存在一箇中央版本庫,全部開發人員本地開發所使用的代碼都是來自於這個版本庫,提交代碼也都必須提交到這個中央版本庫。前端
- 在中央庫上建立或從主幹複製一個分支
- 從中央庫check out 下這個分支的代碼
- 增長本身的代碼文件,修改現存的代碼或刪除代碼文件
- commit代碼,假設有人在剛剛的分支上提交了代碼,你就會被提示代碼過時,你得先up你的代碼後再提交。up代碼的時候若是出現衝突,須要解決好衝突後再進行提交。
- 當沒法鏈接到中央版本庫的環境下,你沒法提交代碼,將代碼加入版本控制;
- 你沒法查看代碼的歷史版本以及版本的變化過程。提交到版本控制系統中的代碼咱們都默認經過自測可運行的,若是某個模塊的代碼比較複雜,不能短期內實現爲可測試的功能,那麼你須要等很長的時間才能提交本身的代碼,因爲代碼庫集中管理,所以,須要對中央版本庫的存儲作備份。這點分佈式的版本控制系統要好一些。Svn的備份要備份全部代碼數據以及全部更改的版本記錄。
git是由Linus開發的,因此很天然的git和Linux文件系統結合的比較緊密,以致於在windows上你必須使用cygwin才能使其完美的工做。
那git憑啥叫作分佈式的版本控制系統呢?仍是從其工做模式講起把。java
- 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庫。linux
對於版本管理系統,運維人員須要掌握的技術點:ios
- 安裝,部署,維護,排障。
- 簡單使用,不少公司都是由開發來管理,包括創建新倉庫和添加刪除帳號
- 對於版本控制系統,運維人員至關於開發商,開發人員是業主,運維
- 搭建的系統爲開發人員服務的。
(1)獨立服務器訪問
訪問地址如:svn://svn.yunjisuan.org/sadoc;git
(2)藉助apache等http服務
訪問地址如:http://svn.yunjisuan.com/sadoc;
a,單獨安裝apache+svn(不要用)
b,CSVN(apache+svn)是一個單獨的整合的軟件,帶web界面管理的SVN軟件程序員
(3)本地直接訪問(例如:file://application/svndata/sadoc)web
SVN客戶端能夠經過多種方式訪問服務器端,例如:本地磁盤訪問,或各類各樣不一樣的網絡協議訪問,但一個版本庫地址永遠都是一個URL,URL反映了訪問方法。shell
訪問方式 | 說明 |
---|---|
file:// | 直接經過本地磁盤或者網絡磁盤訪問版本庫 |
http:// | 經過WebDAV協議訪問支持Subversion的Apache服務器 |
https:// | 與http://類似,可是用SSL加密訪問 |
svn:// | 經過TCP/IP自定義協議訪問svnserve服務器 |
svn+ssh:// | 經過認證並加密的TCP/IP自定義協議訪問svnserve服務器 |
svn存儲版本數據有2種方式:BDB(一種事務安全型表類型)和FSFS(一種不須要數據庫的存儲系統)。由於BDB方式在服務器中斷時,有可能鎖住數據,因此仍是FSFS方式更安全一點。
伯克利DB(Berkeley DB),版本庫可使用的一種通過充分測試的後臺數據庫實現,不能在經過網絡共享的文件系統上使用,伯克利DB是Subversion 1.2版本之前的缺省版本庫格式
一個專用於Subversion版本庫的文件系統後端,可使用網絡文件系統(例如 NFS 或 SMBFS)。是1.2版本及其後的缺省版本庫格式。
集中式代碼管理的核心是SVN服務器,全部開發者在開始新一天的工做以前必須從服務器獲取代碼,而後進行開發,最後解決衝突,提交。全部的版本信息都放在SVN服務器上。所以若是脫離了服務器,開發者就沒法進行提交代碼工做。
開始新一天的工做:
- 首先從SVN服務器下載項目組最新代碼。
- 進入本身的分支,進行開發工做,每隔一小時向服務器上本身的分支提交一次代碼(不少程序員都有這個習慣。由於有時候本身對代碼改來改去,最後又想還原到新一個小時的版本,或者看看前一個小時本身修改了哪些代碼,就須要這樣作了)。
- 下班時間快到了,把本身的分支合併到服務器主分支上,一天的工做完成,並反映給服務器。
- 管理方便,邏輯清晰明確,符合通常人思惟習慣。
- 易於管理,集中式svn服務器更能保證數據安全性。
- 代碼一致性很是高。
- 適合開發人數很少的項目開發。
- 普及度高,大部分軟件配置管理的大學教材都是使用svn和vss。
[root@server ~]# cat /etc/redhat-release CentOS Linux release 7.5.1804 (Core) [root@server ~]# uname -m x86_64 [root@server ~]# uname -r 3.10.0-862.el7.x86_64
[root@server ~]# yum -y install subversion [root@server ~]# rpm -qa subversion subversion-1.6.11-9.el6_4.x86_64
[root@server ~]# mkdir -p /application/svndata #數據存儲根目錄 [root@server ~]# mkdir -p /application/svnpasswd #用戶,密碼權限目錄
建立一個新的Subversion項目yunjisuan,其實,相似yunjisuan這樣的項目能夠建立多個,每一個項目對應不一樣的代碼,這裏只是以建立一個項目爲例演示:
[root@server ~]# svnadmin create /application/svndata/yunjisuan [root@server ~]# tree /application/svndata/yunjisuan/ /application/svndata/yunjisuan/ ├── conf │ ├── authz │ ├── passwd │ └── svnserve.conf ├── db │ ├── current │ ├── format │ ├── fsfs.conf │ ├── fs-type │ ├── min-unpacked-rev │ ├── rep-cache.db │ ├── revprops │ │ └── 0 │ │ └── 0 │ ├── revs │ │ └── 0 │ │ └── 0 │ ├── transactions │ ├── txn-current │ ├── txn-current-lock │ ├── txn-protorevs │ ├── uuid │ └── write-lock ├── format ├── hooks │ ├── post-commit.tmpl │ ├── post-lock.tmpl │ ├── post-revprop-change.tmpl │ ├── post-unlock.tmpl │ ├── pre-commit.tmpl │ ├── pre-lock.tmpl │ ├── pre-revprop-change.tmpl │ ├── pre-unlock.tmpl │ └── start-commit.tmpl ├── locks │ ├── db.lock │ └── db-logs.lock └── README.txt 10 directories, 28 files
[root@server ~]# cd /application/svndata/yunjisuan/conf/ [root@server conf]# ll total 12 -rw-r--r--. 1 root root 1080 Sep 5 18:14 authz -rw-r--r--. 1 root root 309 Sep 5 18:14 passwd -rw-r--r--. 1 root root 2279 Sep 5 18:14 svnserve.conf [root@server conf]# cp svnserve.conf{,.bak} #複製一份配置文件 [root@server conf]# cat -n /application/svndata/yunjisuan/conf/svnserve.conf | sed -n '19p;20p;27p;34p' 19 anon-access = none #禁止匿名訪問 20 auth-access = write #驗證訪問可寫 27 password-db = /application/svnpasswd/passwd #密碼文件位置 34 authz-db = /application/svnpasswd/authz #驗證文件位置 特別提示: 此配置文件裏的每條配置代碼必須頂格寫,不能有空格。
authz
文件和passwd
文件拷貝到/application/svnpasswd
下[root@server conf]# pwd /application/svndata/yunjisuan/conf [root@server conf]# cp /application/svndata/yunjisuan/conf/authz /application/svnpasswd/ [root@server conf]# cp /application/svndata/yunjisuan/conf/passwd /application/svnpasswd/ [root@server conf]# ll /application/svnpasswd/ total 8 -rw-r--r--. 1 root root 1080 Sep 5 18:22 authz -rw-r--r--. 1 root root 309 Sep 5 18:22 passwd
[root@server conf]# svnserve --help #svn啓動命令幫助 svnserve: warning: cannot set LC_CTYPE locale svnserve: warning: environment variable LANG is en svnserve: warning: please check that your locale name is correct usage: svnserve [-d | -i | -t | -X] [options] Valid options: -d [--daemon] : daemon mode #守護進程啓動(後臺) -i [--inetd] : inetd mode -t [--tunnel] : tunnel mode -X [--listen-once] : listen-once mode (useful for debugging) -r [--root] ARG : root of directory to serve #指定根目錄 -R [--read-only] : force read only, overriding repository config file --config-file ARG : read configuration from file ARG --listen-port ARG : listen port #監聽端口默認3690 [mode: daemon, listen-once] --listen-host ARG : listen hostname or IP address #監聽IP [mode: daemon, listen-once] -T [--threads] : use threads instead of fork [mode: daemon] --foreground : run in foreground (useful for debugging) [mode: daemon] --log-file ARG : svnserve log file --pid-file ARG : write server process ID to file ARG [mode: daemon, listen-once] --tunnel-user ARG : tunnel username (default is current uids name) [mode: tunnel] -h [--help] : display this help --version : show program version information
[root@server conf]# svnserve -d -r /application/svndata/ svnserve: warning: cannot set LC_CTYPE locale #警告能夠忽略 svnserve: warning: environment variable LANG is en #警告能夠忽略 svnserve: warning: please check that your locale name is correct #警告能夠忽略 [root@server conf]# netstat -antup | grep 3690 tcp 0 0 0.0.0.0:3690 0.0.0.0:* LISTEN 1256/svnserve
[root@server conf]# source /etc/sysconfig/i18n #啓用中文字符集 [root@server conf]# pkill svnserve [root@server conf]# svnserve -d -r /application/svndata/ [root@server conf]# netstat -antup | grep 3690 tcp 0 0 0.0.0.0:3690 0.0.0.0:* LISTEN 1261/svnserve [root@server conf]# cat /etc/sysconfig/i18n LANG="en_US.UTF-8" SYSFONT="latarcyrheb-sun16"
#在/application/svnpasswd/passwd文件末尾追加以下內容: [root@server conf]# tail -4 /application/svnpasswd/passwd yunjisuan = 123456 yunwei = 123456 stu001 = 123 stu002 = 456
- 權限配置文件中出現的用戶名必須已在用戶配置文件中定義
- 對權限配置文件的修改當即生效,沒必要重啓svn
#用戶組格式: 【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中每一個參數都要頂格寫,開頭不能有空格。 #對於組,要以@開頭,用戶不須要@開頭。
#在authz末尾加入如下幾句代碼 [root@server svnpasswd]# pwd /application/svnpasswd [root@server svnpasswd]# egrep -v "#|^$" /application/svnpasswd/authz [aliases] [groups] sagroup = stu001,stu002 #新增本行,定義組名 [yunjisuan:/] #定義受權的範圍 yunjisuan = rw #用戶單獨受權 yunwei = r #用戶單獨受權 @sagroup = r #組用戶受權
[root@server /]# ps -ef | grep svn | grep -v grep root 1254 1 0 18:26 ? 00:00:00 svnserve -d -r /application/svndata/ [root@server /]# kill 1254 [root@server /]# ps -ef | grep svn | grep -v grep [root@server /]# svnserve -d -r /application/svndata/ [root@server /]# ps -ef | grep svn | grep -v grep root 1285 1 0 18:45 ? 00:00:00 svnserve -d -r /application/svndata/
- 推薦:TortoiseSVN-1.9.7.27907-x64-svn-1.9.7
- 注意:32位系統要用32位軟件版本
一路yes便可
(1)先在本地建立一個目錄,起名任意,好比data
(2)鼠標右鍵點擊data目錄
1)選擇右鍵菜單裏的SVN Checkout,出現下圖:
2)點擊OK後,出現下圖:
3)命令說明:
- SVN Checkout:至關於下載,第一次鏈接svn服務器的時候須要和服務器的對應存儲目錄進行數據同步,若是服務器的對應目錄裏有數據文件,那麼就會下載到你的本地對應目錄裏。
- SVN Update:更新數據,檢查服務器端svn存儲目錄裏是否和本地svn存儲目錄數據不一致,若是不一致,那麼下載改變或新增的部分到本地svn目錄裏。(不會刪除本地目錄內容)
- SVN Commit:提交數據到svn服務器端存儲目錄。本地svn存儲目錄會和服務器端存儲目錄進行比對校驗。會把本地改變的部分和新增的部分同步上傳至服務器端。
(1)向windows的svn存儲目錄data裏放一個空文件
(2)右鍵點擊data目錄,選擇SVN Commit
(3)打開本地data目錄裏的文件,隨便寫點內容後,再次進行SVN commit
(4)直接從本地查看服務器端的數據內容
右鍵點擊本地svn存儲目錄data,選擇TortoiseSVN ===>Repo-browser後出現下圖:
雙擊文件能夠直接遠程打開文件,能夠看到裏面剛剛被修改後的內容已經更新至服務器端。
(5)刪除本地svn存儲目錄data裏的文件,後選擇SVN Update
這時會發現,剛剛刪除的文件又從新下載回來了。
(6)繼續刪除本地svn存儲目錄data裏的文件,後選擇SVN Commit
[root@server locks]# svn --help checkout (co) #下載數據 commit (ci) #提交數據 list (ls) #顯示服務器端內容 update (up) #更新數據
[root@server /]# mkdir yunjisuan [root@server /]# cd yunjisuan/ #下載服務器端數據到Linux本地目錄 [root@server yunjisuan]# svn co svn://192.168.200.72/yunjisuan/ /yunjisuan/ --username=yunwei --password=123456 Restored 'yangwenbo.txt' U yangwenbo.txt Checked out revision 9. [root@server yunjisuan]# ls yangwenbo.txt [root@server yunjisuan]# cat yangwenbo.txt welcome to yangwenbo
[root@server yunjisuan]# svn list file:///application/svndata/yunjisuan/ yangwenbo.txt
[root@server yunjisuan]# pwd /yunjisuan [root@server yunjisuan]# svn co svn://192.168.200.72/yunjisuan/ /yunjisuan/ --username=yunjisuan --password=123456 #換擁有寫入權限的帳戶checkout Restored 'yangwenbo.txt' Checked out revision 9. [root@server yunjisuan]# ls yangwenbo.txt [root@server yunjisuan]# touch {1..5} [root@server yunjisuan]# ll total 4 -rw-r--r--. 1 root root 0 Sep 6 04:10 1 -rw-r--r--. 1 root root 0 Sep 6 04:10 2 -rw-r--r--. 1 root root 0 Sep 6 04:10 3 -rw-r--r--. 1 root root 0 Sep 6 04:10 4 -rw-r--r--. 1 root root 0 Sep 6 04:10 5 -rw-r--r--. 1 root root 20 Sep 6 04:10 yangwenbo.txt [root@server yunjisuan]# svn add * #提交前須要先把要提交的內容作標記A A 1 A 2 A 3 A 4 A 5 svn: warning: W150002: '/yunjisuan/yangwenbo.txt' is already under version control #這個文件已經標記過了 svn: E200009: Could not add all targets because some targets are already versioned svn: E200009: Illegal target for the requested operation [root@server yunjisuan]# svn ci -m "message" #提交時須要同時-m指定一段話做爲備註 Adding 1 Adding 2 Adding 3 Adding 4 Adding 5 Transmitting file data ..... Committed revision 10. #查看服務器端數據 [root@server yunjisuan]# svn list file:///application/svndata/yunjisuan/ 1 2 3 4 5 yangwenbo.txt
- 鉤子腳本的具體寫法就是操做系統中shell腳本程序的寫法,可根據本身的SVN所在的操做系統和shell程序進行相應的開發。
- 鉤子腳本就是被某些版本庫事件觸發的程序,例如:建立新版本或修改未被版本控制的屬性。每一個鉤子都能掌管足夠的信息來了解發生了什麼事件,操做對象是什麼以及觸發事件用戶的帳號。
- 根據鉤子的輸出或返回狀態,鉤子程序可以以某種方式控制該動做繼續執行,中止或掛起。
[root@server /]# ls -l /application/svndata/yunjisuan/hooks/ total 36 -rw-r--r--. 1 root root 1977 Sep 5 06:19 post-commit.tmpl -rw-r--r--. 1 root root 1638 Sep 5 06:19 post-lock.tmpl -rw-r--r--. 1 root root 2289 Sep 5 06:19 post-revprop-change.tmpl -rw-r--r--. 1 root root 1567 Sep 5 06:19 post-unlock.tmpl -rw-r--r--. 1 root root 3426 Sep 5 06:19 pre-commit.tmpl -rw-r--r--. 1 root root 2434 Sep 5 06:19 pre-lock.tmpl -rw-r--r--. 1 root root 2786 Sep 5 06:19 pre-revprop-change.tmpl -rw-r--r--. 1 root root 2122 Sep 5 06:19 pre-unlock.tmpl -rw-r--r--. 1 root root 2780 Sep 5 06:19 start-commit.tmpl
- 對每種Subversion版本庫支持的鉤子都有一個模板,經過查看這些腳本的內容,你能看到是什麼事件觸發了腳本及如何給傳腳本傳遞數據。
- 同時,這些模板也是如何使用這些腳本,結合Subversion支持的工具來完成有用任務的例子。
- 要實際安裝一個可用的鉤子,你須要在repos/hooks目錄下安裝一些與鉤子同名(如start-commit或者post-commit)的可執行程序或腳本,注意,去掉模板的擴展名。
重要提示:
因爲安全緣由,Subversion版本庫在一個空環境中執行鉤子腳本就是沒有任何環境變量,甚至沒有$PATH或%PATH%。因爲這個緣由,許多管理員會感到很困惑,他們的鉤子腳本手工運行時正常,可在Subversion中卻不能運行。要注意,必須在你的鉤子中設置好環境變量或爲你的程序指定好絕對路徑。
鉤子腳本 | 說明 |
---|---|
post-commit | 在提交完成成功建立版本以後執行該鉤子,提交已經完成,不可更改,所以,本腳本的返回值被忽略。提交完成時觸發事務 |
pre-commit | 提交完成前觸發執行該腳本 |
start-commit | 在客戶端尚未向服務器提交數據以前,即尚未創建Subversion transaction以前,執行該腳本(提交前出發事務) |
- pre-revprop-change:在修改revision屬性以前,執行該腳本
- post-revprop-change:在修改revision屬性以後,執行該腳本。由於修改稿已經完成,不可更改,所以本腳本的返回值被忽略(不過實際上的實現彷佛是該腳本的正確執行與否影響屬性修改)
- pre-unlock:對文件進行解鎖操做以前執行該腳本
- post-unlock:對文件進行解鎖操做以後執行該腳本
- pre-lock:對文件進行加鎖操做以前執行該腳本
- post-lock:對文件進行加鎖操做以後執行該腳本。
- 必定要定義變量,主要是用過的命令的路徑。由於SVN的考慮的安全問題,沒有調用系統變量,若是手動執行是沒有問題,但SVN自動執行就會沒法執行了。
- SVN的同步目錄在 update以前必定要先checkout一份出來,還有這裏必定要添加用戶和密碼。
- 加上了對前一個命令的判斷,若是update的時候出了問題,程序沒有退出的話還會繼續同步代碼到Web服務器上,這樣會形成代碼有問題。
- 建議最好記錄日誌,出錯的時候能夠很快的排錯
- 最後是數據同步,rsync的相關參數必定要清楚。
限制上傳文件擴展名及大小,控制提交要輸入的信息等。
- SVN更新自動周知,MSN,郵件或短信周知。
- SVN更新觸發checkout程序,而後實時rsync推送到服務器等。
rsync與svn鉤子結合實現數據實時同步某企業小案例
[root@server /]# mkdir -p /data/www
[root@server /]# svn co svn://192.168.200.72/yunjisuan/ /data/www/ --username=yunjisuan --password=123456 A data/www/5 A data/www/yangwenbo.txt A data/www/1 A data/www/2 A data/www/3 A data/www/4 Checked out revision 10. [root@server /]# ll /data/www/ total 4 -rw-r--r--. 1 root root 0 Sep 6 04:31 1 -rw-r--r--. 1 root root 0 Sep 6 04:31 2 -rw-r--r--. 1 root root 0 Sep 6 04:31 3 -rw-r--r--. 1 root root 0 Sep 6 04:31 4 -rw-r--r--. 1 root root 0 Sep 6 04:31 5 -rw-r--r--. 1 root root 20 Sep 6 04:31 yangwenbo.txt
[root@server /]# cd /application/svndata/yunjisuan/hooks/ [root@server hooks]# cp post-commit.tmpl post-commit [root@server hooks]# cat post-commit REPOS="$1" #傳參(未用上) REV="$2" #傳參(未用上) SvnIP="192.168.200.72" #svn服務端的IP地址 ProjectName="yunjisuan" #svn服務端的項目庫名稱 UserName="yunjisuan" #帳戶姓名 PassWord="123456" #帳戶密碼 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 ${LocalPaht} $SVN checkout svn://${SvnIP}/${ProjectName} ${LocalPath} --username=${UserName} --password=${PassWord} #新建立目錄須要先通過checkout才能update else $SVN update --username yunjisuan --password 123456 /data/www #更新共享目錄內容 fi if [ $? -eq 0 ];then /usr/bin/rsync -az --delete /data/www /tmp/ #數據同步推送到本地/tmp目錄下(生產環境能夠直接同步推送到Web測試服務器) fi
#刪除以前的測試記錄 [root@server hooks]# rm -rf /data/www/* [root@server hooks]# ll -d /data/www ls: cannot access /data/www: No such file or directory [root@server hooks]# rm -rf /tmp/* [root@server hooks]# ll /tmp/ total 0 #給鉤子腳本可執行權限 [root@server hooks]# chmod 700 post-commit [root@server hooks]# ll post-commit -rwx------. 1 root root 611 Sep 6 04:38 post-commit
特別提示:當用戶經過svn更新鉤子post-commit所在的項目庫時,在更新完畢以後會自動觸發鉤子腳本
#svn服務器端本地共享目錄 [root@server /]# ll data/www/ total 4 -rw-r--r--. 1 root root 0 Sep 6 05:20 1 -rw-r--r--. 1 root root 0 Sep 6 05:20 123.txt -rw-r--r--. 1 root root 0 Sep 6 05:20 2 -rw-r--r--. 1 root root 0 Sep 6 05:20 3 -rw-r--r--. 1 root root 0 Sep 6 05:20 4 -rw-r--r--. 1 root root 0 Sep 6 05:20 5 -rw-r--r--. 1 root root 13 Sep 6 05:20 yangwenbo.txt #推送後的數據目錄 [root@server /]# ll /tmp/www/ total 4 -rw-r--r--. 1 root root 0 Sep 6 05:20 1 -rw-r--r--. 1 root root 0 Sep 6 05:20 123.txt -rw-r--r--. 1 root root 0 Sep 6 05:20 2 -rw-r--r--. 1 root root 0 Sep 6 05:20 3 -rw-r--r--. 1 root root 0 Sep 6 05:20 4 -rw-r--r--. 1 root root 0 Sep 6 05:20 5 -rw-r--r--. 1 root root 13 Sep 6 05:20 yangwenbo.txt
開發每次修改完代碼就直接提交,而後經過FTP直接更新到Web服務器網頁目錄;沒有專門的測試人員,徹底是由用戶來進行測試體驗。
(1)小型企業現狀:
小型公司通常只有幾個開發人員,網站核心程序大多數都是PHP語言開發,爲了方便,會直接經過FTP直接上傳程序代碼到線上服務器,隨時隨地上線更新。
(2)上述上線方案的特色和問題:
- 發佈快,及時,隨時隨地就能夠發佈代碼。
- 開發人員發佈的代碼不通過測試人員的測試,且用戶訪問頁面刷新後頁面即改變,也可能刷新瞬間程序在更新,到時沒法訪問,對網站用戶的體驗比較差,若是開發寫錯了代碼,形成的影響就更大了,這是拿用戶做爲測試的上線方案。
- 據統計,網站中大概50%以上的故障是和開發程序代碼有關的,(好比:開發寫錯了一個循環代碼,致使了死循環,此時大量用戶訪問這個程序,就能把服務器資源耗盡,搞死服務器)
- 在中小公司網站出了問題通常是運維人員的問題(例如網站宕機),但這種狀況下,問題大多可能由開發人員或代碼引發的,這裏比較好的策略是開發項目負責制思想。
(3)小型企業上線架構方案建議:
- 開發人員需在我的電腦搭建LAMP環境測試開發好的網站代碼,而且在辦公室或IDC機房的測試環境測試經過,最好有專職測試人員。
- 程序代碼上線規定時間,例如,三天上線一次,如網站需常常更新可天天下午17點上線,這個看網站業務性質而定,原則就是影響用戶體驗最小。
- 代碼上線以前需備份,網站程序出了問題方便回退,另外,網站程序出了問題方便回退,另外,從上線技巧上講,上傳代碼時儘量先傳到服務器網站臨時目錄,傳完整後一步mv過去,或者經過ln作軟鏈接。(線上更新代碼思路)
- 務必由運維人員管理上線,對於代碼的功能性,開發人員更在乎,而對於代碼的性能和服務的穩定,運維更在乎,所以,若是網站問題歸運維管,就要讓運維上線這樣更規範科學。不然,開發隨意更新,出了問題運維負責,這樣就錯了。
中型企業上線,通常是規範運維人員操做步驟,制定統一的上線操做腳本,備份文件名稱,備份文件路徑。使操做人性化,統一化,自動化。
Web代碼的上線流程演示圖:
大型企業上線通常制度和流程控制較多,比較嚴謹,下面是某大型企業上線解決方案架構:
(1)SVN裏的內容:
- 程序代碼
- 服務的配置
- 項目文檔,設計文檔,運維部署優化文檔
(2)門戶大型網站架構環境代碼上線具體方案:
- 本地開發人員從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分組上線的思路,即平滑下線一半的服務器,而後發佈更新代碼測試,無問題後,掛上服務器,同時在平滑下線另外一半的服務器,而後發佈更新代碼測試(或者直接發佈後就掛上線)
(3)PHP程序代碼上線的具體方案:
對於PHP上線方法:發佈代碼時(也須要測試流程)能夠直接發佈到正式線臨時目錄,而後mv或更改link的方式發佈到正式線目錄,不須要重啓http服務。這是sina,ganji的上線方案。
(4)JAVA程序代碼上線的具體方案:
對於java上線方法:較大公司須要分組平滑上線,例如,首先從負載均衡器上摘掉一半的服務器,發佈代碼後,重啓服務器測試,沒問題後,掛上通過測試的這一半,再下另一半。若是前端有DNS智能解析,上線還能夠分地區上線若干服務器,逐漸普及到全國的服務器,這個被稱爲灰度發佈。
(1)SINA網的代碼發佈流程邏輯圖:
(2)什麼是配置管理員呢?
就是在開發和運維中間起一個鏈接紐帶的一個職位,這個職位通常在大公司裏會設置,負責SVN的管理,上線管理,申請,協調等工做。
對於門戶網站或重視規範或開發能力較強的公司也許會結合系統服務和WEB界面管理來更科學更自動的進行上線代碼管理,如開發一個自動化代碼上線部署平臺,其實就是一個web管理界面(界面底層調用相關腳本實現分發推送代碼以及重啓服務器),而後普通的初級上線人員就能夠在平臺裏實現僅僅點鼠標,敲回車,就能實現平滑上線和平滑回滾代碼了,固然,自動化和完善的程度也許沒咱們說的這麼好,可是,思路是這樣的。下面就是管理平臺的一個圖例:
開發自動化部署平臺的思路不少,咱們能夠經過nagios的被動模式實現上線管理平臺原理思路:
- 實際上就是生成配置在分發服務器上執行命令請求,應用服務器,而後腳本在應用服務器處理完畢後回傳結果到web界面顯示:
- 例如:check_nrpe -h 10.0.0.178 -c check_load
- 變動管理制度流程有利於業務穩定。
- 保留變動業務歷史,便於覈查發現的問題。
- 故障跟蹤平臺,有利於跟蹤問題的解決進度,而不是半途而廢