分享

测试思想

 犇馆长 2018-03-26



 

目录

一、         创建根目录

二、         创建版本库

三、         修改版本库基础配置

四、         启动SVN

五、         客户端访问

六、         目录规划

七、         代码管理与版本控制

 

 

一、 创建根目录

创建一个空文件夹,例如 svn,作为所有版本库的根目录

[root@localhost ~]# mkdir -p /svn/

 

二、 创建版本库

进入svn目录,创建版本库

[root@localhost ~]# cd /svn/

[root@localhost svn]# svnadmin create --fs-type fsfs project1

 

三、 修改版本库基础配置

Ø  修改authz

[root@localhost conf]# vim authz

……

[groups]

# harry_and_sally = harry,sally

# harry_sally_and_joe = harry,sally,&joe

group = shouke

 

……

# [repository:/baz/fuz]

# @harry_and_sally = rw

# * = r

[project1:/]

@group = rw

 

Ø  修改svnserve.conf配置

[root@localhost conf]# vim svnserve.conf

……

[general]

……

anon-access = read

auth-access = write

……

password-db = passwd

……

authz-db = authz

 

Ø  新增svn用户

[root@localhost conf]# useradd shouke

[root@localhost conf]# passwd shouke

Changing password for user shouke.

New password:

BAD PASSWORD: The password is shorter than 8 characters

Retype new password:

passwd: all authentication tokens updated successfully.

 

注:设置的用户密码为 123456

 

Ø  修改password配置文件

[root@localhost conf]# vim passwd

……

[users]

# harry = harryssecret

# sally = sallyssecret

shouke=123456

 

Ø  修改authz配置文件

[root@localhost conf]# vim authz

……()

[groups]

# harry_and_sally = harry,sally

# harry_sally_and_joe = harry,sally,&joe

group1 = shouke

……

# [repository:/baz/fuz]

# @harry_and_sally = rw

# * = r

[project:/]

@group1 = rw

 

 

四、 启动SVN

[root@localhost conf]# svnserve -d -r /svn/

 

说明:-d 表示以daemon的方式运行,-r dir_path 表示把dir_path当作版本库的根目录,比如 /svn/reposvn://192.168.1.103/repo,访问的就是/svn/repo

 

查看

[root@localhost conf]# netstat -antp | grep svn

tcp        0      0 0.0.0.0:3690            0.0.0.0:*               LISTEN      8474/svnserve  

说明:如上,默认端口为3690

 

五、 客户端访问

 

 测试思想-流程规范 <wbr>SVN代码管理与版本控制

 

六、 目录规划

 

测试思想-流程规范 <wbr>SVN代码管理与版本控制

目录说明:

code:用于存放代码

doc:用于存放文档,比如初始化sql脚本

 

master

线上主分支,存放线上最新“稳定版”代码,该分支永的代码远处于随时可发布的状态。

 

develop

开发主分支,存放开发状态下,相对稳定的“开发版”代码--完成了某个新功能或者修改某个bug、某个功能后的开发稳定版本。不管开发新需求对应的新功能,还是进行局部功能修改,非紧急bug修复,都是从该分支拉取对应的分支进行开发。

 

feature_branche

功能分支,存放开发阶段的代码。从develop拉取的分支,供开发人员进行bug修复、功能改造、新功能开发。

 

说明:这里可以根据实际需要,可以拉取多个分支,进行并行开发。通常,我们会把一次迭代中大功能拆分成小功能点,分配给不同的开发人员去实现,这样,每个功能点对应一个分支,实现之后再合并到develop

 

release_branch

预发布分支。从develop拉取的分支(只在第一次),存放预发布环境对应的代码。

 

tag

按代码版本存档,存放的是master的备份,只读不写。

 

七、 代码管理与版本控制

测试思想-流程规范 <wbr>SVN代码管理与版本控制

 

 

 

 


测试思想-流程规范 <wbr>SVN代码管理与版本控制

说明:

开发阶段:

当线上形成一个稳定版本后,开发阶段,先从master merge代码到develop,然后从develop拉取feature_branch分支,开发人员基于对应的feature_branch进行功能开发

 

测试阶段:

当开发人员完成开发任务并merge内容到develop后,测试人员需要构建jenkins上对应任务项目,将代码部署到测试环境,测试。

 

当测试环境测试通过后,开发人员需要把develop的内容mergerelease_branch, 测试人员需要构建jenkins上对应任务项目,将代码部署到预发布环境,测试。

 

部署阶段:

当预发布环境测试通过后,开发人员需要把release_branch的内容mergemaster, 运维人员构建jenkins上对应任务项目,将代码部署到线上环境,测试人员进行测试,测试通过则为mastertag,归档。

 

如果预发布测试发现存在问题,测试不通过,开发人员在release_branch上进行bug修复,然后测试人员在预发布环境验证,测试通过则先mergemaster,运维人员构建jenkins上对应任务项目,将代码部署到线上环境,测试人员进行测试,测试通过则为mastertag,归档,同时还要将release_branch的内容mergedevelop

 

平日维护

平日开发阶段,如果发现已发布线上的版本存在紧急bug,那么开发人员在release_branch上进行bug修复,然后测试人员在预发布环境验证,测试通过则先mergemaster,运维人员构建jenkins上对应任务项目,将代码部署到线上环境,测试人员进行测试,测试通过则为mastertag,归档,同时还要将release_branch的内容有选择的mergedevelop

 

注:用jenkins实现代码构建并自动部署,需要在jenkins新建的项目中配置源代码svn路径,这时候如果svn路径没有参数化,则开发人员每次拉取feature_branch后,需要手动设置代码路径为对应分支的代码路径,以便构建时能拉取到对应分支的代码。这里masterrelease_branchdevelop仅保留一份代码,目录名称等保持不变,所以其在jenkins上配置的svn源代码路径为固定的,不需要改来改去。

 


    本站是提供个人知识管理的网络存储空间,所有内容均由用户发布,不代表本站观点。请注意甄别内容中的联系方式、诱导购买等信息,谨防诈骗。如发现有害或侵权内容,请点击一键举报。
    转藏 分享 献花(0

    0条评论

    发表

    请遵守用户 评论公约

    类似文章 更多