配置管理方案.docx
- 文档编号:10712484
- 上传时间:2023-02-22
- 格式:DOCX
- 页数:26
- 大小:569.35KB
配置管理方案.docx
《配置管理方案.docx》由会员分享,可在线阅读,更多相关《配置管理方案.docx(26页珍藏版)》请在冰豆网上搜索。
配置管理方案
元征科技配置管理方案(草稿)
深圳元征科技有限公司版权所有
CopyrightownershipbelongstoGUIYI,shallnotbereproduced,copied,orusedinotherwayswithoutpermission.OtherwiseGUIYIwillhavetherighttopursuelegalresponsibilities.
作者:
何美平
审核:
批准:
日期:
版本:
V1.0
1.前言
1.1.目的
本文档针对目前公司的产品/项目规划、研发、发布、系统实施等提出整体的配置管理解决方案。
1.2.背景
1.2.1.配置管理现状
随着公司新平台版本的规划,以及旧的版本出现的亟待解决的各种问题,配置管理方面主要以下问题:
1、产品版本发布缺乏规划,需求缺乏管理;
2、产品版本的发布没有专人持续管理,后续跟踪与反馈缺失,版本混乱不清,失去控制,如果产品版本出现问题,难以快速定位,增加解决难度和成本;
3、已发布的产品的版本没有集中管理,更不能对历史数据进行查询,统计,总结;
4、构建与发布由各项目开发和测试负责,可能会人员经常变动,且占用专门开发、测试人员的工作量,没有流程化,自动化,效率低下,出错率高;
5、资源存储分散,不能及时有效获得;
6、变更管理流程没有执行,现有的变更流程形同虚设,变更变得不可控;
7、公司的共享资源没有很有效的管理;
8、现有的流程和制度没有得到强有力的执行,已经实施的制度,没有保障执行的效果等。
1.2.2.源码管理现状
现状:
使用windows端的visualSVN作为版本管理工具,服务器是PC机
原因:
1.Windows平台操作简单,不需要技术功底
2.Linux服务器跨网段访问有问题
3.当时人员少规模不大,用PC作为临时性的服务器
随着项目的发展,人数已经增长到150人,一年内有可能增加到500人,因此其限制就很明显
缺点:
1.windowsOS不如linux安全稳定
2.台式机服务器会有性能上的问题,不利于长远的扩展
3.
4.旧SVN上版本库的数量繁多凌乱,目录结构不清晰不规范,不是非常熟悉的人要找到想要的东西非常困难
5.目前功能也不完整,只具备核心的版本库的管理,不支持个人帐户修改密码,也没有备份机制
6.综合而言整个服务器处在非常危险的境地
1.2.3.产品现状
现有的产品,有的已经发布多个版本,从20130919到20140123,基本都是各模块单独发布,不知道集成时的版本关系,有版本混乱,去向不明,根据问题反馈又找不到对应版本的问题。
没有文档说明,拿到版本也不知如何部署运行;没有releasenote也不知道哪些问题在什么版本得到解决,哪些功能从哪个版本开始有等。
现有产品目前的版本发布情况如下图:
2.产品运行的几个环境
2.1.开发环境
用于各个业务的共同的开发调试环境,可提供数据库、php后台、java后台的集成调试。
开发环境的信息:
(由开发各业务组自己管理)
服务器IP:
192.168.85.212
Mysql DB:
MangoDB:
OracleDB:
客户端连接开发环境使用的URL:
2.2.测试环境
开发调试没问题之后,可提交测试环境,用于测试人员的测试验证。
测试环境可提供正式发布前的所有功能测试,但因服务器性能限制,无法提供压力测试。
测试环境的信息:
(目前由CM管理)
服务器IP:
192.168.85.210(内网)119.145.230.34(外网) 公网域名:
开通的映射端口有:
a)上传服务:
119.145.230.34:
8888 --->192.168.85.210:
2492;
b) 网页访问(nginx):
119.145.230.34:
8008--->192.168.85.210:
8008
c) 网页访问(tomcat):
119.145.230.34:
8000 --->192.168.85.210:
8000
d) 远程诊断:
119.145.230.34:
9001 --->192.168.85.210:
9001
e)IM:
119.145.230.34:
10101~10104 --->192.168.85.210:
10101~10104
测试环境的数据库
a)Mysql DB:
192.168.85.209 各业务的数据库访问的端口号、用户名、密码同生产环境一致
b)MangoDB:
192.168.85.209 无用户名密码
c)OracleDB:
192.168.85.209 各业务的数据库访问的端口号、用户名、密码同生产环境一致
d)数据库访问:
http:
//192.168.85.210/phpMyAdmin帐户:
golo/temp12345
缓存的配置
a)Redis:
192.168.85.208 其他配置跟正式环境一样
b)Memocache:
192.168.85.208(尚未安装)
各业务的URL和服务器文件的对应关系是:
a):
8008/application ->/data/golo/app_application/wwwroot/
b):
8008/dev -> /data/golo/app/wwwroot/
c):
8008/clog -> /data/golo/app_log/wwwroot/
d):
8008/file -> /data/golo/app_file/wwwroot/
e):
8008/inner -> /data/golo/app_inner/wwwroot/
f):
8008/pub -> /data/golo/site_public/wwwroot/ 公众帐号平台
g):
8008/public -> /data/golo/app_public/wwwroot/
h):
8008/share -> /data/golo/app_share/wwwroot/
i):
8008/system -> /data/golo/system_admin/wwwroot/
j):
8008/odata/app -> /data/odata/OData.app/wwwroot/
k):
8008/odata/boss -> /data/odata/boss/wwwroot/
l):
8008/odata/gathercenterwebapi -> /data/odata/OData.gathercenterwebapi/wwwroot/
m):
8008/odata/gathermessagequeueapi -> /data/odata/OData.gathermessagequeueapi/wwwroot/
n):
8008/odata/log -> /data/log/
o):
8008/odata/openapi -> /data/odata/OData.openapi/wwwroot/
p):
8008/odata/triprecordinfo -> data/odata/OData.triprecordinfo/wwwroot/
q):
8000 -> /opt/MyCar
r):
8000/ucenter -> /usr/local/apache-tomcat/webapps/ucenter/
客户端连接开发环境使用的URL:
:
8008/dev
2.3.预发布环境(待建)
2.4.生产环境(由运维部管理)
3.源码版本管理
现状:
使用windows端的visualsvn作为版本管理工具
缺点:
7.windowsOS不如linux安全稳定
8.台式机服务器会有性能上的问题,不利于长远的扩展
9.旧SVN上版本库的数量繁多凌乱,目录结构不清晰不规范,不是非常熟悉的人要找到想要的东西非常困难
10.目前功能也不完整,只具备核心的版本库的管理,不支持个人帐户修改密码,也没有备份机制
11.综合而言整个服务器处在非常危险的境地
源代码管理使用subversion作为源代码的版本管理工具,服务器端部署在linux服务器上。
该工具以差异化方式存储文本和二进制文件,任何一次提交都会产生一个revision,相当于一个版本记录,又不会导致库容量很大,并且能很好的支持分支与合并。
在实际的使用中,我们对源码的管理分为产品研发库和系统实施库两大类进行管理。
3.1.研发新库
研发库新库是针对平台新版本的源码、文档、工具、资源等所有相关文件的版本管理库,因为关键、主要的是源代码部分,因此也统称源代码的版本管理库。
1、配置管理工程师建库,建立标准目录,并给产品组成员分配权限(已经建立:
http:
//svnserver/svn/)
a)迁移用户使用原来的用户名,默认密码与用户名相同,请通过http:
//svnserver/cgi-bin/svnpass.cgi修改密码
b)迁移库根目录使用原先相同的名字(全小写)
2、通知所有产品组人员,产品配置库完成创建。
附上配置库的连接路径、权限清单、目录结构说明、注意事项。
3、目录使用说明:
产品的源码库管理根据运行的不同环境分成三个支线来管理:
a)开发环境:
b)Trunk:
开发主线,产品设定一个基础版本作为主线进行开发;
c)Branches:
开发支线,根据产品不同的应用版本创建不同的应用分支,开发自己维护各支线;
d)Release:
可选。
用于php、java后台增量发布时,存放发布版本;
e)Tags:
保存基线和版本标签。
正式发布的版本,其完整的源码,文档在tags做基线管理;
f)新库的进一步细化的目录结构、新库源码管理的示意图见下图:
Golo库:
存放golo的客户端,包括ios和android的,其目录结构如下:
Diag库:
存放诊断相关的项目和接头相关的,其目录结构如下:
platform库:
存放php后台的项目和需求管理系统,其目录结构如下:
appcenter库:
存放java后台的各项目,其目录结构如下:
权限规划:
按项目经理的要求划分权限,并通过林总审核。
3.2.研发旧库(备份库)
旧库上的各项目的历史版本,已经迁移到备份库,可根据要求来开放只读权限,所有的历史版本和log备查。
备份库的地址是:
http:
//svnserver/svn/backup
3.3.库迁移(已完成)
旧库到新库的迁移方案,项目的新旧目录对比参见此文档:
3.4.源码库管理规定
新的SVN库有如下使用规则:
1.用户的帐户统一使用姓名的全拼,部分用户与旧库中的帐号不一致,因为旧库中使用了好几种规则,故在此统一;
2.默认密码是跟用户名相同,请在使用前在此修改密码:
http:
//svnserver/cgi-bin/svnpass.cgi;
3.申请权限需通过项目经理,并指定目录及权限,发邮件给CM,并抄送给林强;
4.Trunk为主开发目录,由项目经理确定成员对各目录的权限
5.如果有分支,需要另给出权限清单,不可与trunk中的相冲突
6.Tags目录所有人只有读权限;
7.为了留下有意义的提交记录,设定了必须在每次提交时需要输入注释,并不少于10个字符;
8.目前制定的目录规范,可根据需求扩展,但原则不变;
9.请大家相同的文件只存放在相应的位置,不需要冗余存储,尽量少存放二进制文件,发布包存放在专门的发布服务器。
10.如果需要建立新的版本开发,请联系配置管理员创建分支,而不要重新上传一份。
4.构建与发布
4.1.每日构建(持续集成)
构建:
是指将系统从源码到安装部署的过程,通过工具jenkins实现自动化构建。
构建建成后可以:
1.对每日的提交进行每日构建(也称持续集成)
2.作为发布流程的一个环节,生成build提交测试、UAT测试并至最终发布
3.需要建立持续集成的项目除了php,nodejs等非编译语言的项目。
每日构建的好处:
1.对相关人员及时展示项目研发进展;
2.统一出入口,保证代码版本的正确性、可用性和可追溯性;
3.提高编码质量;
4.提高开发人员与测试人员之间工作衔接的效率;
5.减少开发人员和测试人员工作量,提高工作效率;
6.减少构建花费的时间,提高发布效率;
7.可灵活配置,扩展性强,搭建好了之后,容易维护。
构建是通过管理上和技术上的手段来完成。
需要有严格的管理规则来保证构建的顺利进行。
1.所有项目构建环境均由配置管理组统一在构建服务器上搭建、运行;
2.所有svn库操作人员严格遵守《元征科技研发配置管理规范》所规定的内容;
3.开发人员及时提交可编译通过代码入库;
4.构建中,自动化集成仅对各种组件、应用的集成,相关组件、应用的接口均需由相关功能组提供,包含自动部署的安装、启动自动化测试等。
5.构建服务器由CM管理;
6.项目提供正确的开发、部署和运行环境;
7.开发人员使用规定统一的的开发工具和环境;
8.开发人员编写代码符合《编码规范》;
9.开发进行每日构建,提交测试的构建按项目初始约定频率进行提交,每个项目会运行两套构建程序,一套用于测试环境,一套用于正式环境。
构建的基本流程如下:
1.约定构建运行日程,客户端高峰期是上班时间每小时运行一次,自动执行;
2.项目组构建接口人在构建启动前提交releasenote入库;
3.获取源码(项目组提供源码路径和revision号,默认从trunk线上获取),若要不影响继续开发,请负责人指定svn中源码的revision号码;
4.自动编译输出;
5.运行代码检查工具,单元测试;(可选)
6.生成安装包或可执行程序集包;
7.部署、分发
a)非提交测试的版本:
部署到共享服务器、开发服务器;
b)提交测试的版本:
i.自动测试:
部署到测试服务器,并运行测试脚本
ii.手动测试:
可以选择测试人员自己部署,或自动部署到测试服务器
8.在共享服务器上运行冒烟测试脚本,若没有通过,修改后重新构建;(可选)
9.通过冒烟测试:
a)非提交测试的版本:
邮件通知相关人员构建完成
b)提交测试的版本:
将安装包更新到svn中的release目录,需要手工测试,人工部署时,测试人员从该位置获取最新版本部署
10.邮件通知结果。
4.2.产品发布
Golo产品的发布,包括了java后台,php后台、app客户端等不同业务版本测试完成后,形成基线,可对外发布的活动。
按产品的形态可分为客户端发布、java后台的发布,php后台的发布;按发布的不同对象又分为测试发布、正式发布。
在产品发布前,产品管理相关人员先要提供短中期的产品版本规划,CM需要掌握每个业务的版本清晰的脉络结构。
4.2.1.客户端(app)发布流程
客户端需要根据不同的运行环境编译生成不同版本的apk/ipa文件。
1.测试人员默认每天取前一天的最后一个版本测试;
2.测试已经通过的版本,测试人员发出通知,包括《测试报告》,版本号,测试结果等信息;
3.项目经理根据测试结果决定是否正式发布;
4.如果确定要发布,项目经理通知相关人员做好发布准备。
a)开发人员整理并提交releasenote
b)CM创建发布基线
c)产品经理提交正式版本到电子市场
5.产品经理提交到电子市场后,邮件通知本次发布信息给相关部门相关人员。
内容包括客户端发布的版本号,releasenote,可下载的电子市场等。
(图未更新)
4.2.2.服务端(php后台)的发布流程
php程序不需要编译,发布和部署都是直接以文件的方式进行。
服务端的发布围绕客户端进行,版本号与客户端一致。
测试版本的发布:
指的是将开发验证过的代码从svn服务器上取出,部署到测试环境中去。
正式版本的发布:
指的是将测试验证通过的代码/文件,部署到正式环境中去。
4.2.2.1.测试版本发布
服务端的测试版本部署在测试环境()下,需要客户端的测试版本来配合测试,比如android3.1.1的版本,正式版本的测试apk是golo_3.1.1_Rn.apk,测试版本的测试apk则是golo_3.1.1_Rn_test.apk;
具体的过程如下描述:
1.开发人员提交代码到trunk 主线,并将修改的文件列表提交给运维、CM。
到release目录,按版本号存放;如:
.3.1.1的存放路径是:
http:
//svnserver/svn/platform/platform-common/release/3.1.1;
2.CM从对应的版本目录更新文件到测试环境;
3.CM通知测试人员使用测试版本的客户端开始测试验证(网站的验证可直接在测试环境的目录下进行);
4.测试验证过程,测试人员向bug系统提交bug,开发人员解决,转bug处理流程;
5.Bug解决后,再次验证通过,转正式发布流程
4.2.2.2.正式版本发布
正式版本部署在生产环境中,客户端的测试版本也相应的要变成正式环境的版本。
1.测试版本测试通过之后,由测试人员出具测试报告、版本号,测试结果等信息;
2.发布工程师将通过测试的版本(文件列表)提交到正式环境(通过自动发布系统);
3.测试人员(不限此类)做确认验证;
4.CM创建发布基线(tags目录);
5.转客户端的发布;
6.发布完成。
4.2.3.紧急情况发布
对于生产环境出现的问题,为了修复紧急问题或为了快速响应新的需求,对应简单的修改需要忽略测试的环节,走紧急发布流程的情况,视为紧急情况发布。
其流程如下:
1.项目经理确定是否属紧急情况,必须要立即更新生产环境属于紧急情况的发布;
2.项目经理指定任务负责人,开发人员,DBA或者UI/UE;
3.任务负责人完成后直接联系发布工程师,部署到生产环境;
4.发布工程师将部署的文件备份,并通知CM提交回SVN库的相关目录;
5.CM提交到SVN,并做补丁基线;
5.发布版本注释(releasenote)
无论是大版本,还是补丁、升级包的发布,都需要提供Releasenote需要包含以下主要内容:
●产品信息,包含软、硬件,子系统和模块,历史版本,源码路径,产品包路径等;
●实施部署的方案和步骤;
●版本关联的需求、任务、bug。
对于产品发布版本管理,考虑采用wikipage系统进行管理
6.变更管理(待补充)
7.资源管理
资源管理通过工具平台和权限手段将技术中心所有的资源有效的组织利用管理起来,主要包括办公软件、开发和调试工具、公共文档、规范等,以及人员在工作中累积的经验(包括原创,收集的文档),实践过的优秀的工具等资源的分享与交流。
通过资源的合理管理,不仅能提供一个标准有序的工作环境,提高工作效率。
通过经验的分享和交流还能对公司和个人的发展具有极大的推动作用。
7.1.提供统一的工作环境标准
对于同类产品、项目相关需要建立一个统一的工作环境标准,所使用的工具、组件、技术采用相同版本,防止由于工作环境不统一所带来的不兼容等问题,提高工作效率。
7.2.文件共享(由信息部规划实现)
在文件共享服务器(ftp:
//
7.3.知识库
建立知识库平台,将所有相关资料、众人的智慧和宝贵的经验通过文档,分享到知识库的平台,既能使大家获取知识,提升个人能力,还能增加同事间的交流。
目前我们用JSPwiki平台来实现这类共享。
地址:
Jspwiki简介:
Jspwiki是一个免费开源的知识管理系统,用于组织和共享文档。
可以通过名称,内容,关键字等来搜索文档。
有以下特点:
1.超文本格式的知识分享系统,支持中文;
2.可多人协作编辑,支持权限管理;
3.能保留网页每一次更动的版本,即使参与者将整个页面删掉,管理员也会可以从纪录中恢复最正确的页面版本;
4.支持页面锁定:
一些主要页面可以用锁定技术将内容锁定,其他人就不可再编辑了。
5.版本对比:
WiKi站点的每个页面都有更新纪录,任意两个版本之间都可以进行对比,WiKi会自动找出他们的差别。
6.更新描述:
你在更新一个页面的时候可以在描述栏中写上几句话,如你更新内容的依据、或是跟管理员的对话等。
这样,管理员就知道你更新页面的情况。
7.IP禁止:
尽管WiKi倡导人人都可参与,但如果有少部分恶意破坏者,WiKi有记录和封存IP的功能。
8.SandBox(沙箱)测试:
一般的WiKi都建有一个SandBox的页面,这个页面就是专门用于让初次参与的人先到SandBox页面做测试,SandBox与普通页面是一样的,这里你可以任意涂鸦、随意测试。
9.编辑规则:
任何一个开放的WiKi都有一个编辑规则,上面写明了大家建设维护WiKi站点的规则。
没有规矩不成方圆的道理任何地方都是适用的。
使用规范:
1.Wiki更关内容不关心格式,所以我们更注重内容不必关心格式。
2.拥抱变化,接受共同频繁修改,群策群力,沉淀精华。
3.专题汇总研究并分享,适用于专题培训
4.页面用名字用英文(比如:
ThisAPage),这样移植方便。
5.不推荐大量转存互联网内容,请增加连接即可。
6.不推荐上传大量文件附件,如果需要请放到ftp或是SVN服务器,增加连接即可。
8.服务器规划
1.服务器的规划图
2.现有服务器的使用情况(待整理)
No
地址
型号
cpu
内存
硬盘
系统
登陆
1
192.168.83.232
(新SVN服务器)
Cetos6.5x64
Svn服务器
Root/root@golo
2
192.168.85.216
(旧svn服务器)
Win7
VisualSvn服务器
Admin/fdsafdsa
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 配置管理 方案
![提示](https://static.bdocx.com/images/bang_tan.gif)