自動化運維-【版本流程管理】

時間 2019-12-01

標籤自動化版本流程管理欄目測試自動化简体版

原文原文鏈接

什麼是版本控制系統(VCS)

版本控制系統 (VCS) 是一個軟件，幫助軟件開發人員團隊工做並維持他們完整的工做歷史。 下面是版本控制系統(VCS) 的目標php

容許開發者們同時工做
不會重寫每一個人的改變
維持每一個版本的所有的歷史

VCS 被分紅兩種css

集中版本控制系統 (CVCS)
分散或不集中的版本控制系統 (DVCS)

學習svn用到的術語html

倉庫: 倉庫是任何一個版本系統的核心，它是開發者們保存工做的總部，倉庫不止處理文件還有歷史記錄，它須要訪問網絡，扮演服務器的角色，版本控制工具扮演客戶端的角色，客戶端能夠鏈接倉庫，那麼他們就能夠從倉庫中存儲或者提取。經過保存這些更改，一個客戶端的更改能夠被其餘人檢索到，一個客戶端可讓其餘人的更改做爲一個工做副本。

主幹：trunk 是主要開發所在的目錄，常常被項目開發者們查看。

標籤：tags 目錄用於儲存項目中被命名的快照，標籤操做容許給予對倉庫中特定版本一個描述和一個難忘的名字。好比，LAST_STABLE_CODE_BEFORE_EMAIL_SUPPORT 比 Repository UUID: 7ceef8cb-3799-40dd-a067-c216ec2e5247 和Revision: 13 更使人難忘。

分支：分支操做用於建立開發的另外一條線，當你想把開發進程複製進兩個不一樣的方向是頗有用的。好比，當你發佈 5.0 版本時，你可能想從 5.0 的 bug 修復中分離出來建立一個開發 6.0 功能的分支。

工做副本：工做副本是倉庫的一個快照。這個倉庫被全部的成員共享，但人們不直接修改它，相反每一個開發者檢查這個工做副本，工做副本是一個私人的工做空間，這裏開發者能夠獨立於其餘成員作本身的工做。

提交更改：提交是一個保存更改的過程，從私人工做空間到中央服務器。提交後，更改對所有成員可用，經過更新工做副本其餘開發者提取這些更改。提交是一個原子操做，要麼所有提交成功要麼回滾，用戶毫不會看到一半完成提交。

svn前端

1.SVNjava

1.1簡介node

SVN是Subversion的簡稱，是一個開放源代碼的跨平臺的開源的版本控制系統，相較於RCS、CVS，它採用了分支管理系統，它的設計目標就是取代CVS。互聯網上不少版本控制服務已從CVS遷移到Subversion。說得簡單一點SVN就是用於多我的共同開發同一個項目，共用資源的目的
svn版本管理工具管理隨着時間改變的各類數據，這些數據放置在一箇中央資料檔案庫中，svn會備份並記錄每一個文件每一次的修改變更，這樣咱們就能夠把任意一個時間點的檔案恢復到一箇舊的版本。

svn相關站點：
　　svn客戶端：http://www.tortoisesvn.net
　　官方手冊：http://svnbook.red-bean.com

svn與git的區別
　　svn:是集中式的版本控制系統，存在一箇中央版本庫，全部開發人員本地開發所使用的代碼都是來源版本庫，提交代碼也必需要提交到這個版本庫
　　　　 svn的備份要備份全部代碼數據，以及全部更改的版本記錄，也能夠直接備份中央代碼庫
　　git：是分佈式的版本控制系統，在git中，已經沒有了中央版本庫的說法了，可是有遠程和本地的完整的git倉庫，用來開發小組的代碼共享
　　　　  其中本地和遠程倉庫中的代碼是等價的，沒有主從之分

1.2 運行方式，訪問方式和數據存儲linux

svn服務器有3種運行方式：
　　獨立服務器 ：svn://svn.test.com/object
　　apache運行:http://svn.test.com/object
　　　　1.單獨安裝svn和apache服務器
　　　　2.第二種是csvn（apache+svn），是一個單獨整合個軟件，帶web界面的svn軟件
　　svn服務器本地直接訪問：file:///application/svndata/sadoc

svn客戶端的訪問方式：

　　數據存儲git

　　　　svn存儲版本數據也有2種方式：BDB(一種事務安全型表類型)和FSFS(一種不須要數據庫的存儲系統)。由於BDB方式在服務器中斷時，有可能鎖住數據，因此仍是FSFS方式更安全一點。web

　　　　在svn1.2之前的版本使用BDB,1.2之後使用FSFSshell

　　　　SVN是基於關係數據庫的(BerkleyDB)或一系列二進制文件的(FS_FS)。一方面這解決了許多問題 (例如，並行讀寫共享文件)以及添加了許多新功能(例如運行時的事務特性。)。然而另外一方面，數據存儲由此變得不透明。

1.3 svn版本系統邏輯架構原理

1.4 集中式管理工做的流程圖

集中式代碼管理的核心是服務器，全部開發者在開始新一天的工做以前必須從服務器獲取代碼，而後開發，最後解決衝突，提交。全部的版本信息都放在服務器上。若是脫離了服務器，開發者基本上能夠說是沒法工做的。下面舉例說明：
開始新一天的工做：
1、從服務器下載項目組最新代碼。
2、進入本身的分支，進行工做，每隔一個小時向服務器本身的分支提交一次代碼，不少人都有這個習慣。由於有時候本身對代碼改來改去，最後又想還原到前一個小時的版本，或者看看前一個小時本身修改了哪些代碼，就須要這樣作了。
3、下班時間快到了，把本身的分支合併到服務器主分支上，一天的工做完成，並反映給服務器。
這就是經典的svn工做流程，從流程上看，有很多缺點，但也有優勢。優缺點參考

集中式管理工做的流程圖

2.配置SVN服務

2.1查看系統環境

[root@node1 /]# cat /etc/redhat-release 
CentOS Linux release 7.4.1708 (Core) 
[root@node1 /]# uname -a
Linux node1 3.10.0-693.el7.x86_64 #1 SMP Tue Aug 22 21:09:27 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
[root@node1 /]# uname -r
3.10.0-693.el7.x86_64
[root@node1 /]# uname -m
x86_64
[root@node1 /]#

2.2安裝svn(subversion)

檢查是否安裝了svn
[root@node1 /]# svn --version 
-bash: svn: command not found

安裝svn
[root@node1 /]# yum install subversion -y

yum安裝rpm包本地不清除的方法
[root@node1 /]# cat /etc/yum.conf 
keepcache=0 #0修改成1，rpm包下載後不清除


查看版本
[root@node1 /]# rpm -qa subversion
subversion-1.7.14-14.el7.x86_64

配置並啓動
　　1.創建svn版本庫數據存儲的目錄(svndata)及用戶，密碼權限目錄(svnpassword)
　　　　[root@node1 /]# mkdir -p application/svndata #數據存儲的根目錄
　　　　[root@node1 /]# mkdir -p application/svnpasswd #用戶密碼權限目錄
　　2.使用命令svnserve啓動服務
　　　　[root@node1 /]# svnserve -d -r /application/svndata || pkill svnserve 中止svn服務
　　　　　　svnserve -d -r 目錄 --listen-port 端口號
　　　　　　-d：表示啓動以守護進程的方式啓動
　　　　　　-r：配置方式決定了版本庫訪問方式
　　　　　　--listen-port：指定SVN監聽端口，不加此參數，SVN默認監聽3690
　　　　　　--listen-host：指定SVN監聽的host，不加此參數，默認所有監聽
　　　　　　--pid-file：存放進程號文件
　　更多svnserve參數：man svnserve
　　3.查看是否啓動，端口爲3690
　　　　[root@node1 /]# ps -ef |grep svn
　　　　root     16304     1  0 18:59 ?        00:00:00 svnserve -d -r /application/svndata/
　　4.建立版本庫（能夠建立多個，放置不一樣的代碼）
　　　　[root@node1 /]# svnadmin create /application/svndata/sadoc
　　　　svnadmin --help 能夠查看svnadmin用法
　　5.調整svn配置文件及權限文件
　　　　[root@node1 conf]# cd /application/svndata/sadoc/conf  #版本庫的配置文件目錄
　　　　[root@node1 conf]# ll 
　　　　total 12
　　　　-rw-r--r-- 1 root root 1080 Nov  8 20:03 authz  #用戶權限驗證文件
　　　　-rw-r--r-- 1 root root  309 Nov  8 20:03 passwd #用戶密碼文件
　　　　-rw-r--r-- 1 root root 3090 Nov  8 20:03 svnserve.conf  #sadoc版本庫主配置文件，而且包含上面兩個配置文件

　　　　修改以前要作備份 tar -zcvf ./back_tar.gz . 
　　　　編輯svnserve.conf修改如下四項：注意修改後要從新啓動
　　　　　　anon-access = none    #不容許匿名訪問，read是容許匿名訪問
　　　　　　auth-access = write   #是否支持用戶可寫
　　　　　　password-db = /application/svnpasswd/passwd  #指定用戶密碼數據庫，方便統一管理
　　　　　　authz-db = /application/svnpasswd/authz      #用戶權限數據庫
　　　　將用戶模板copy到配置文件指定的路徑裏面
　　　　　　[root@node1 conf]# cp authz passwd /application/svnpasswd/
　　　　進入/application/svnpasswd修改文件屬性，增長安全性，只有root用戶可讀
　　　　　　[root@node1 svnpasswd]# chmod 700 *
　　　　編輯passwd添加帳號密碼，由於帳號密碼是明文的，因此上一步修改文件權限，修改後不用從新啓動
　　　　　　[root@node1 svnpasswd]# vim passwd 
　　　　　　p0st = 123456
　　　　　　shuang = 123456

　　　　配置用戶權限文件
　　　　注意：
　　　　　　權限配置文件中出現的用戶名必須是已在用戶配置文件中定義過的
　　　　　　對權限配置文件的修改當即生效，沒必要從新啓動svn

　　　　　　[groups] #gtoups下面的變量就是組名，後面可抱哈你多個用戶名，用逗號隔開
　　　　　　# harry_and_sally = harry,sally
　　　　　　# harry_sally_and_joe = harry,sally,&joe
　　　　　　ett_wang = p0st,shuang

　　　　　　# [repository:/baz/fuz] 版本庫:/版本庫項目/項目目錄 #因此這裏既能夠給整個組賦權限，也能夠給單個用戶賦權限
　　　　　　# @harry_and_sally = rw 用戶組名:權限
　　　　　　# * = r 用戶名:權限

　　　　　　[sadoc:/]
　　　　　　@ett_wang = rw
　　　　　　p0st = rw
　　　　　　shuang = r

　　　　　　其中方括號內部有不少種寫法
　　　　　　[/]，表示根目錄及如下，這裏的根目錄指的是svnserve啓動時指定的，[/]就表示對所有版本庫的設置權限
　　　　　　[svndata:/]表示對版本庫svndata設置權限
　　　　　　[svndata:/sadoc]表示對版本庫svndata中的sadoc設置權限
　　　　　　[svndata:/sadoc/test]表示對版本庫svndata中的sadoc項目的test項目設置權限

　　　　　　權限主體能夠是用戶組，用戶，或者*，用戶組在前面加@。*表示所有用戶
　　　　　　權限能夠是w,r,wr和空，空表明沒有任何權限
　　　　　　對於組，要以@開頭，用戶不須要@開頭

　　　　　　使用diff authz authz.bak 能夠進行對比，查看文件不一樣

　　6.重啓svn服務：
　　　　[root@node1 svnpasswd]# pkill svnserve 
　　　　[root@node1 svnpasswd]# svnserve -d -r /application/svndata/ 
　　　　注意： 更改svnserve.conf須要重啓svn，更改authz、passwd文件時不須要重啓； 
　　　　檢查3690端口是否處於監聽狀態，至此svn服務器搭建完成；下面是svn客戶端的安裝與使用；
　　　　只有更改了svnserve.conf才須要重啓服務，剩下的更改都是當即生效的不須要重啓

2.3svn啓動方式

svnserve -d -r 目錄 --listen-port 端口號
-r: 配置方式決定了版本庫訪問方式。
--listen-port: 指定SVN監聽端口，不加此參數，SVN默認監聽3690

方式一：-r直接指定到版本庫(稱之爲單庫svnserve方式)
svnserve -d -r /opt/svn/runoob
在這種狀況下，一個svnserve只能爲一個版本庫工做。
authz配置文件中對版本庫權限的配置應這樣寫：[groups]
admin=user1
　　dev=user2
　　[/]
　　@admin=rw
　　user2=r
使用相似這樣的URL：svn://192.168.0.1/　便可訪問runoob版本庫

方式二：指定到版本庫的上級目錄(稱之爲多庫svnserve方式)
svnserve -d -r /opt/svn
這種狀況，一個svnserve能夠爲多個版本庫工做
authz配置文件中對版本庫權限的配置應這樣寫：
[groups]
admin=user1
dev=user2
[runoob:/]
@admin=rw
user2=r

[runoob01:/]
@admin=rw
user2=r
若是此時你還用[/]，則表示全部庫的根目錄，同理，[/src]表示全部庫的根目錄下的src目錄。
使用相似這樣的URL：svn://192.168.0.1/runoob　便可訪問runoob版本庫。

2.3 鏈接svn服務器

windows：
　　下載tortoisesvn（windos上面svn工具），安裝，若是英文看不懂，能夠安裝中文包漢化
　　輸入用戶名和密碼，複選框能讓tortoisesvn的缺省目錄：%APPDATA%\Subversion\auth的三個子目錄內保存認證信息
　　svn.simple：裏面包含了進本的認證方式所需的認證信息，注意，密碼是經過wincrpty的api加密的不是明文
　　svn.ssl.server：裏面包含了ssl服務器認證
　　svn.username：裏面包含了用戶名的認證信息（不須要提供密碼）
　　新建一個文件夾用來接收svn如今的內容，在文件夾上右鍵就有不少功能了
linux：
　　在linux使用svn時，要安裝svn

　　　查看svn中的數據
　　 svn list svn://192.168.10.231/sadoc --username=p0st --password=123456
　　 svn ls svn://192.168.10.231/sadoc --username=p0st --password=123456
　　 svn ls svn://192.168.10.231/sadoc --username=p0st --password=123456 --verbose #能夠顯示詳細的信息
　　 svn cat svn://192.168.10.231/sadoc/hosts --username=p0st --password=123456 #能夠查看文件內容

　　 checkout:檢出文件到本地
　　 svn checkout svn://192.168.10.231/sadoc /tmp --username=p0st --password=123456
　　命令下載地址下載到哪裏（本地服務器）帳號密碼

　　 add:往版本庫中添加新的文件,可是還沒提交進去
　　 svn add hosts

　　將添加或者改動的文件提交到版本庫
　　svn commit -m 「LogMessage「 [-N] [--no-unlock] PATH(若是選擇了保持鎖，就使用–no-unlock開關)
　　svn commit -m hosts
　　備註：提交多個文件中間用空格隔開如 svn ci -m "哈哈~~" test.php test2.php style.css

　　若是出現編碼錯誤的話，須要制定utf-8的編碼方式
　　 export LC_CTYPE="en_US.UTF-8"
　　 export LC_ALL=
　　 locale

　　導入svn原始目錄樹 trunk（主幹） branch（分支）tag（肯定以後的版本號）
　　 svn import
　　 mkdir -p /svn/trunk /svn/branch /svn/tag
　　 svn import /svn file:////application/svndata/ -m "import"
　　 svn import /svn svn://192.168.10.231/sadoc/ --username=p0st --password=123456 -m 「import是註釋」

　　將主幹保存爲分支
　　svn copy svn://192.168.10.231/sadoc/trunk svn://192.168.10.231/sadoc/branch/branch_cms_110623 -m "create a branch by p0st"

　　查看當前svn版本庫的信息svn info
　　 svn://192.168.10.231/sadoc --username=p0st --password=123456　

　　注意：要是用svn help 或者svn help add 等命令來查看怎麼使用

　　其餘命令

3.svn鉤子腳本

3.1鉤子簡介

鉤子腳本的具體寫法就是操做系統中shell腳本程序的寫法，所謂鉤子就是與一些版本庫事件觸發的程序，例如新修訂版本的建立，或是未版本化屬性的修改。每一個鉤子都會被告滿足夠多的信息，包括那是什麼事件，所操做的對象，和觸發事件的用戶名。經過鉤子的輸出或返回狀態，
鉤子程序能讓工做繼續、中止或是以某種方式掛起。相似inotify和sersync

對每種Subversion版本庫支持的鉤子的都有一個模板，經過查看這些腳本的內容，你能看到是什麼事件觸發了腳本及如何給傳腳本傳遞數據。同時，這些模版也是如何使用這些腳本，結合Subversion支持的工具來完成有用任務的例子。要實際安裝一個可用的鉤子，
你須要在 repos/hooks目錄下安裝一些與鉤子同名（如 start-commit或者post-commit）的可執行程序或腳本。

提示：
　　因爲安全緣由，Subversion版本庫在一個空環境中執行鉤子腳本—就是沒有任何環境變量，甚至沒有$PATH或%PATH%。因爲這個緣由，許多管理員會感到很困惑，它們的鉤子腳本手工運行時正常，可在Subversion中卻不能運行。
　　要注意，必須在你的鉤子中設置好環境變量或爲你的程序指定好絕對路徑。
　　必需要去掉項目裏面鉤子的後綴名

3.2鉤子腳本

注意：svn鉤子的目錄在/application/svndata/sadoc/hooks下，該目錄已經提供了幾個鉤子的模板

經常使用的鉤子腳本

post-commint：在提交完成成功以後執行該鉤子，提交已經完成不會更改，所以，本腳本的返回值被忽略，不可更改，提交完成時觸發事物　　　

　　1.svn更新自動周知，msn，郵件或者短信

　　2.svn更新觸發checkount程序，而後rsync實時推送到服務器等　

#此腳本是在commit以後，svn版本庫進行更新，而且將版本庫裏面的內容經過rsync推送到/oldboy備份

#!/bin/bash
#REPOS='$1'
#REV='$2'
#export LANG=en_US.UTF-8
#export LC_ALL=
#LOGPATH="/app/log.log"
#[ ! d $LOGPATH ] && mkdir ${LOGPATH} -p
#update content from svn
SVN=/usr/bin/svn
$SVN update --username p0st --password 123456 /tmp --no-auth-cache

#$SVN update --username p0st --password 123456 /tmp --no-auth-cache >>$LOGPATH 2>&1
if [[ $? -eq 0 ]]; then
/usr/bin/rsync -az --delete /tmp /oldboy/
fi

注意：
　　1.鉤子使用時，要去掉後綴名，能夠cp post-commit.tmpl post-commit
　　2.若是是在windos寫的腳本，在linux上執行腳本要進行轉換格式 dos2unix post-commint 或者使用編輯器打開時:set ff=unix,而後:wq
　　3.鉤子要有執行權限，一般是700,若是有亂碼，能夠將腳本中的文件系統的編碼註釋去掉,特別要注意環境變量的使用，能夠查看狗子的模板中是怎麼使用的

　　重點：常見的鉤子使用方法鉤子詳解

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

　　1.用做限制文件上傳大小和擴展名，控制提交要輸入的信息等

start-commit：在客戶端尚未向服務器提交數據以前，即尚未創建subversion transaction縮寫爲（txn）以前，執行該鉤子（腳本）

不經常使用的鉤子腳本

svn經過ldap統一認證

4.大中小企業代碼發佈解決方案

4.1svn目錄組織結構說明

[root@node1 svndata]# pwd
/application/svndata
[root@node1 svndata]# ls -al
drwxr-xr-x 6 root root 58 Nov  9 20:06 .
drwxr-xr-x 4 root root 38 Nov  9 17:22 ..
drwxr-xr-x 2 root root  6 Nov  9 20:06 branch #分支，爲測試使用，幾天上線的項目必須開分支，測試須要本分支經過，主線合併到分支經過，才能合併到主線進行測試
drwxr-xr-x 6 root root 86 Nov  9 17:23 sadoc #版本庫
drwxr-xr-x 2 root root  6 Nov  9 20:06 tags  #版本記錄使用
drwxr-xr-x 2 root root  6 Nov  9 20:06 trunk #主線，與正式線相對應，當天不上線文件不容許提交

4.2大中小企業上線解決方案

　　小型企業上線架構方案

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

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

　　中型企業上線架構方案

中型企業上線構架方案建議

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

　　大型企業上線架構方案

在大型集羣環境通常有數臺集羣機器，所以要分批更新。
下面是java環境代碼上線：
1.本地開發人員從svn中抽取代碼，當天上線的提交到trunk，不然，長期項目單開分支開發，而後合併主線（trunk）
2.辦公內網開發測試時，由開發人員或者配置管理員經過部署jenkins實現統一部署（即在部署平臺式控制開發機器從SVN版本庫中checkout代碼，編譯，打包，發佈到開發機，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），而後發佈到idc內的統一分發服務器主機上，準備批量發佈
7.配置管理員和sa上線人員，把分發的內容推送到相關的正式服務器（包名：idc_product.war）,而後通知開發以及測試人員進行測試，若是有問題，直接發佈回滾指令

注意：idc正式上線的過程對於java程序來講，能夠將集羣上的服務器分爲ab兩組分批上線的思路，即在流量較少的時候平滑下線一半的服務器，在測試集羣掛上服務器。而後進行代碼測試，無問題後，在正式集羣掛上服務器，同時在平滑下線另外一半的服務器，而後發佈更新代碼測試（或者直接發佈就上線）若是前端有dns智能解析，上線還能夠分地區的若干服務器，逐漸普及到全國的服務器，這個稱爲灰度發佈

4.3大中小企業上線注意事項

代碼上線解決方案注意事項：
1.上線的流程裏，辦公測試環境->idc測試環境->正式生產環境，全部的環境中全部的軟件版本統一，儘可能單一。例如：操做系統，web服務器，jdk版本，php，tomcat，resin等版本
2.開發團隊小組辦公內部測試環境測試（該測試環境屬於開發小組維護，或定時自動更新代碼），代碼有問題返回給開發人員從新開發
3.有專門的測試工程師，程序有問題直接返回給開發人員（此時返回的通常爲程序的bug，稱爲bug庫），無問題則進行idc測試
4.idc測試有測試人員和運維人員參與，叫idctest，進行程序的壓力測試，有問題直接返回給開發人員，無問題直接環境上線
5.書檯服務器代碼分發上線（java程序）
1）假設有六臺服務器，將服務器分爲ab兩組，a三臺，b三臺，先對a組從負載均衡服務器上平滑下線，b組正常提供服務器，避免服務器因線上影響業務
2）下線過程當中經過腳本將a組服務器從集羣中踢出，避免負載均衡器將請求發給a組服務器
3）將代碼發到a租服務器的站點目錄下，對a組服務器在測試負載均衡器上線並重啓，並有專門的測試人員進行訪問測試，測試成功後，在正式負載均衡器上掛上a租服務器的同事，下線b組服務器，b組服務器作和a組等同操做，期間也要及時觀察上線服務器的裝魯昂，有問題及時回滾
6.若是php上線：發佈代碼時，能夠直接發佈到正式服務器的臨時目錄，而後mv或者直接link的方式發佈到正式線目錄，不須要重啓服務，固然測試也是少不了的，測試出了測試是否正常之外，還須要測試各個相關業務接口
7.大多數門戶網站的前端都已經靜態化或者cache了，所以動態的部分訪問平時就不會特別多，流量低谷時就號了，再加上是平滑上下線，用戶感知更小

php程序上線的具體方案 對於php上線：發佈代碼時，能夠直接發佈到正式服務器的臨時目錄，而後mv或者直接link的方式發佈到正式線目錄，不須要重啓服務

4.4svn服務器上到底要包含什麼？

 1）svn上存放代碼（不含資源，大公司的網站資源和程序都是分離的），在上線的時候儘量要全量上線，由於咱們要保證svn的代碼是最新的
 2）存放服務的配置文件（lamp環境等配置）
     開發小組測試使用的配置文件
     辦公環境測試使用的配置文件
     idc環境測試使用的配置文件
     線上應用使用的配置文件

相關標籤/搜索

每日一句

每一个你不满意的现在，都有一个你没有努力的曾经。