连接: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
- 变动管理制度流程有利于业务稳定。
- 保留变动业务历史,便于核查发现的问题。
- 故障跟踪平台,有利于跟踪问题的解决进度,而不是半途而废