配置管理方案

1、元征科技配置管理方案（草稿）深圳元征科技有限公司版权所有Copyright own ership bel ongs to GUIYI, shall not be reproduced , copied, or used in other ways without permissi on. Otherwise GUIYI will have the right to pursue legal resp on sibilities.作者何美平审核批准日期版本V1.0目录1. 前言31.1. 目的312背景31.2.1. 配置管理现状 31.2.2. 源码管理现状31.2.3. 产品现状52. 产品

2、运行的几个环境 52.1. 开发环境52.2. 测试环境62.3. 预发布环境（待建）72.4. 生产环境（由运维部管理）73. 源码版本管理73.1. 研发新库73.2. 研发旧库113.3. 库迁移113.4. 源码库管理114. 构建与发布（待补充） 124.1. 构建124.2. 产品发布154.2.1. 客户端（app）发布 154.3. 实施部署164.4. 紧急补丁发布 174.5. 升级包发布错误!未定义书签。5. 发布版本注释（release note） 176. 变更管理（待补充） 187. 资源管理187.1. 提供统一的工作环境标准 187.2. 文件共享（由信息部规划

3、实现） 187.3. 知识库188. 服务器规划199. 服务器安全管理（待完善）239.1. 备份管理239.2. 业务连续性方案（待补充） 231. 刖言1.1. 目的本文档针对目前公司的产品/项目规划、研发、发布、系统实施等提出整体的配置管理解决方案。1.2. 背景1.2.1. 配置管理现状随着公司新平台版本的规划，以及旧的版本出现的亟待解决的各种问题，配置管理方面主要以下问题:1、产品版本发布缺乏规划，需求缺乏管理；2、产品版本的发布没有专人持续管理，后续跟踪与反馈缺失，版本混乱不清，失去控制，如果产品版本出现问题，难以快速定位，增加解决难度和成本；3、已发布的产品的版本没有集中管理，

4、更不能对历史数据进行查询，统计，总结；4、构建与发布由各项目开发和测试负责，可能会人员经常变动，且占用专门开发、测试人员的工作量，没有流程化，自动化，效率低下，出错率高；5、资源存储分散，不能及时有效获得；6、变更管理流程没有执行，现有的变更流程形同虚设，变更变得不可控；7、公司的共享资源没有很有效的管理；8、现有的流程和制度没有得到强有力的执行，已经实施的制度，没有保障执行的效果等。1.2.2. 源码管理现状现状：使用windows端的visualSVN作为版本管理工具，服务器是PC机原因：1. Windows平台操作简单，不需要技术功底2. Linux服务器跨网段访问有问题3. 当时人员少

5、规模不大，用PC作为临时性的服务器随着项目的发展，人数已经增长到150人，一年内有可能增加到500人，因此其限制就很明显缺点:1. windows OS不如linux安全稳定2. 台式机服务器会有性能上的问题，不利于长远的扩展文件 选顶 直看（V）帮助gfx内存vwwya * w'ivri-L.nMnrrvi wrrm UUBLRMLLWAUML1.33物理内存個总颤已镰存可用应用程庠|进程i服勢 性能|联网|用户i CPU使用CPU o记录枷理胸存使用记录闾件 统栖程程机面 系旬线进开页ZZ353771S7lZTl：5Z：Zii108TIA / 410SM资腺槪述L9697内存100

6、匚RJ网第嚴盘.3干字苛於 0%刚络利用胃兄-九*已用物理内存4. 旧SVN上版本库的数量繁多凌乱，目录结构不清晰不规范，不是非常熟悉的人要找到想要的东西非常困难5. 目前功能也不完整，只具备核心的版本库的管理，不支持个人帐户修改密码，也没有备份机制6. 综合而言整个服务器处在非常危险的境地1.2.3. 产品现状现有的产品，有的已经发布多个版本，从20130919到20140123，基本都是各模块单独发布，不知道集成时的版本关系，有版本混乱，去向不明，根据问题反馈又找不到对应版本的问题。没有文档说明，拿到版本也不知如何部署运行；没有release note也不知道哪些问题在什么版本得到解决，哪

7、些功能从哪个版本开始有等。现有产品目前的版本发布情况如下图:J.友茹严品 DemohistaryVersranVersiorl 0 0-2013C807-Q1 -持卡人刊可亲统,.historyVersKin客服系绒 內就布系魏| dbJ .企业WEB至缆,.20130Q191 )2013092720130930： ；20131006,.201310122013101420131016M131017AFilaExtariaon1§GYBPM.zip lipap三2. 产品运行的几个环境2.1.开发环境php后台、java后台的集成调试。用于各个业务的共同的开发调试环境，可提供数据库、

8、 开发环境的信息：（由开发各业务组自己管理）服务器 IP: Mysql DB:Mango DB:Oracle DB：客户端连接开发环境使用的URL:22测试环境开发调试没问题之后，可提交测试环境，用于测试人员的测试验证。测试环境可提供正式发布前的所有功能测 试，但因服务器性能限制，无法提供压力测试。测试环境的信息：(目前由CM管理)服务器 IP: (内网)(外网) 公网域名：开通的映射端口有：a) 上传服务：: 8888 ;b) 网页访问(nginx): : 8008 c) 网页访问: 8000 d) 远程诊断：: 9001e) IM: : 测试环境的数据库a) Mysql DB: 各业务的数

9、据库访问的端口号、用户名、密码同生产环境一致b) Mango DB: 无用户名密码c) Oracle DB： 各业务的数据库访问的端口号、用户名、密码同生产环境一致d) 数据库访问： 帐户：golo/temp12345缓存的配置a) Redis : 其他配置跟正式环境一样b) 尚未安装)各业务的URL和服务器文件的对应关系是：a) :8008/applicationb) :8008/dev->c) :8008/clog->d) :8008/file ->e) :8008/inner->f) :8008/pub->g) :8008/public ->h) :8

10、008/share->i) :8008/systemj) :8008/odata/app-> /data/golo/app_applicati on/wwwroot/data/golo/app/wwwroot/data/golo/app_log/wwwroot/data/golo/app_file/wwwroot/data/golo/app_ inn er/wwwroot/data/golo/site_public/wwwroot/ 公众帐号平台/data/golo/app_public/wwwroot/data/golo/app_share/wwwroot/-> /data

11、/golo/system_adm in/wwwroot/-> /data/odata/OData.app/wwwroot/k) -> /data/odata/boss/wwwroot/l) ->/data/odata/OData.gatherce nterwebapi/wwwroot/-> /data/odata/OData.gathermessagequm)eueapi/wwwroot/n):8008/odata/logo):8008/odata/open apip):8008/odata/triprecordinfo-> /data/log/->/dat

12、a/odata/OData.ope napi/wwwroot/->data/odata/OData.triprecord in fo/wwwroot/q) -> /opt/MyCarr) -> /usr/local/apache-tomcat/webapps/uce nter/ 客户端连接开发环境使用的URL： 23预发布环境（待建）24 生产环境（由运维部管理）3. 源码版本管理现状：使用 windows端的visualsvn作为版本管理工具缺点：7. windows OS不如linux安全稳定8. 台式机服务器会有性能上的问题，不利于长远的扩展9. 旧SVN上版本库的数量

13、繁多凌乱，目录结构不清晰不规范，不是非常熟悉的人要找到想要的东西非常困难10. 目前功能也不完整，只具备核心的版本库的管理，不支持个人帐户修改密码，也没有备份机制11. 综合而言整个服务器处在非常危险的境地源代码管理使用subversion作为源代码的版本管理工具，服务器端部署在linux服务器上。该工具以差异化方式存储文本和二进制文件，任何一次提交都会产生一个revision，相当于一个版本记录，又不会导致库容量很大，并且能很好的支持分支与合并。在实际的使用中，我们对源码的管理分为产品研发库和系统实施库两大类进行管理。3.1. 研发新库研发库新库是针对平台新版本的源码、文档、工具、资源等所有

14、相关文件的版本管理库，因为关键、主要的是 源代码部分，因此也统称源代码的版本管理库。1、配置管理工程师建库，建立标准目录，并给产品组成员分配权限（已经建立：http:/svnserver/svn/ ）a）迁移用户使用原来的用户名，默认密码与用户名相同，请通过 nserver/cgi-bi n/svnpass.cgi修改密码b）迁移库根目录使用原先相同的名字（全小写）2、通知所有产品组人员，产品配置库完成创建。附上配置库的连接路径、权限清单、目录结构说明、注意事项。3、 目录使用说明：产品的源码库管理根据运行的不同环境分成三个支线来管理：a）开发环境：b）Trun k:开发主线，产品设定一个基础

15、版本作为主线进行开发；c）Branches：开发支线，根据产品不同的应用版本创建不同的应用分支，开发自己维护各支线；d) Release：可选。用于php、java后台增量发布时，存放发布版本；e) Tags：保存基线和版本标签。正式发布的版本，其完整的源码，文档在tags做基线管理;f) 新库的进一步细化的目录结构、新库源码管理的示意图见下图：大产品产品A按模块划分目录tru nkbran chestagsJdoc I.desig n里程碑或归档的 版本在此存放并行开发分支从trunk 出维护版本分支从tag出个人分支其他分支如修改bug等RD可根据需 要修改和 调整userguide pr

16、ojectma na geme nt testotherdocGolo库：存放golo的客户端，包括ios和an droid的，其目录结构如下:."http；/19 2,16&,83.2 3 2/svn/goi - Repository Browser - TortoiseUR.L: (TFfcExtebrarKhesdoc tags.tnjnk丿h ttp:/232/svn rgoloJ ancfroad)brandies* dcxl> , design> h 0由旳projertTiariaemerkt» J. 9> te吐> ,LfSE

17、ngutde.toss. trunk“ golo_daccontrclleddcc,o±ersj. pr oductm angenent> I UE> ,.»spublic卜 serverDiag库：存放诊断相关的项目和接头相关的，其目录结构如下:URL： http:/192.163.S3.232/evn/diag/publicj tittp;/19LlS8.3332/svn/diagFilt *Jacitolairich> 1brandies.branchesJIdocdocdesign.uqsPotherstruilcprcjcctmBnagement

18、,.RD.tsstusergubdeptagsfunk0 ,crp也diagdoc> 1controlleddoc1others> 1productmangem er tpUE0 ,easydiagb耳icfeg0 |maxigaD i耐 xmusP ,Spubik0iscmnpadWl0 1.scanpad LO1t> Nx431pro0彳x431pro3X431V0 JjH3 lvplusplatform库：存放php后台的项目和需求管理系统，其目录结构如下:UKL!炉 http: /'svns erv er/svn /platfb rm/p<fltfior

19、ni -commonFiletranches doojmerit rtlu日s亡 tags trunkh ftp: /svnserver/s vnfplatform J lapdbranches docurvie nt、release> tags> trunk.platfiorm_ck)cJ phtfoE'Convnon鼻 branchespdev0. dev_it>testtest_lD S讣-doajTTientrelease鼻tagstag_2OL311L5>.tBg_201312O3teg .20131204 tag_2O1312L7:trunkappc

20、enter库：存放java后台的各项目，其目录结构如下:权限规划：按项目经理的要求划分权限，并通过林总审核。32研发旧库（备份库）log备查。旧库上的各项目的历史版本，已经迁移到备份库，可根据要求来开放只读权限，所有的历史版本和备份库的地址是：http:/svnserver/svn/backup3.3. 库迁移（已完成）旧库到新库的迁移方案，项目的新旧目录对比参见此文档:svnlist.xlsx34源码库管理规定新的SVN库有如下使用规则：1. 用户的帐户统一使用姓名的全拼，部分用户与旧库中的帐号不一致，因为旧库中使用了好几种规则，故在此统；2. 默认密码是跟用户名相同，请在使用前在此修改密码

21、：http:/svnserver/cgi-bin/svnpass.cgi ;3. 申请权限需通过项目经理，并指定目录及权限，发邮件给CM,并抄送给林强；4. Trunk为主开发目录，由项目经理确定成员对各目录的权限5. 如果有分支，需要另给出权限清单，不可与 trunk中的相冲突6. Tags目录所有人只有读权限；7. 为了留下有意义的提交记录，设定了必须在每次提交时需要输入注释，并不少于10个字符；8. 目前制定的目录规范，可根据需求扩展，但原则不变；9. 请大家相同的文件只存放在相应的位置，不需要冗余存储，尽量少存放二进制文件，发布包存放在专门的发布 服务器。10. 如果需要建立新的版本开

22、发，请联系配置管理员创建分支，而不要重新上传一份。4. 构建与发布4.1. 每日构建（持续集成）构建：是指将系统从源码到安装部署的过程，通过工具jenkins实现自动化构建。构建建成后可以:1. 对每日的提交进行每日构建（也称持续集成）2. 作为发布流程的一个环节，生成build提交测试、UAT测试并至最终发布3. 需要建立持续集成的项目除了php, nodejs等非编译语言的项目。每日构建的好处：1. 对相关人员及时展示项目研发进展；2. 统一出入口，保证代码版本的正确性、可用性和可追溯性；3. 提高编码质量；4. 提高开发人员与测试人员之间工作衔接的效率；5. 减少开发人员和测试人员工作量

23、，提高工作效率；6. 减少构建花费的时间，提高发布效率；7. 可灵活配置，扩展性强，搭建好了之后，容易维护。构建是通过管理上和技术上的手段来完成。需要有严格的管理规则来保证构建的顺利进行。1 .所有项目构建环境均由配置管理组统一在构建服务器上搭建、运行；2 .所有svn库操作人员严格遵守元征科技研发配置管理规范所规定的内容；3. 开发人员及时提交可编译通过代码入库；4. 构建中，自动化集成仅对各种组件、应用的集成，相关组件、应用的接口均需由相关功能组提供，包含自动部 署的安装、启动自动化测试等。5. 构建服务器由CM管理；6. 项目提供正确的开发、部署和运行环境；7. 开发人员使用规定统一的的

24、开发工具和环境；8 .开发人员编写代码符合编码规范 ；9 .开发进行每日构建，提交测试的构建按项目初始约定频率进行提交，每个项目会运行两套构建程序，一套用于测试环境，一套用于正式环境。构建的基本流程如下:1. 约定构建运行日程，客户端高峰期是上班时间每小时运行一次，自动执行；2. 项目组构建接口人在构建启动前提交release note入库；3. 获取源码（项目组提供源码路径和revision号，默认从trunk线上获取），若要不影响继续开发，请负责人指定svn中源码的revision号码；4. 自动编译输出；5. 运行代码检查工具，单元测试；（可选）6. 生成安装包或可执行程序集包；7. 部

25、署、分发a）非提交测试的版本：部署到共享服务器、开发服务器；b）提交测试的版本：i. 自动测试：部署到测试服务器，并运行测试脚本ii. 手动测试：可以选择测试人员自己部署，或自动部署到测试服务器8. 在共享服务器上运行冒烟测试脚本，若没有通过，修改后重新构建；（可选）9. 通过冒烟测试：a）非提交测试的版本：邮件通知相关人员构建完成b）提交测试的版本：将安装包更新到svn中的release目录，需要手工测试，人工部署时，测试人员从该位置获取最新版本部署10. 邮件通知结果。启动构建V7代码、 release note 入库 *获取源码解决问题不通过构建失败通知通过目标文件分发生成发布包构建成功

26、通知是（自动测试）提交测试1.自动部署到测试服务器2.运行测试脚本自动部署或 手动部署部署到部署到开发服务器部署服务器解决问题是（手动测试）I冒烟测试不通过缺陷跟踪系统通过产品服务器提交测试更新svn的 release 目录测试过程F测试通过F构建完成 邮件发布通知42 产品发布Golo产品的发布，包括了 java后台，php后台、app客户端等不同业务版本测试完成后，形成基线，可对 外发布的活动。按产品的形态可分为客户端发布、java后台的发布，php后台的发布；按发布的不同对象又分为测试发布、正式发布。在产品发布前，产品管理相关人员先要提供短中期的产品版本规划，CM需要掌握每个业务的版本清

27、晰的 脉络结构。4.2.1. 客户端(app)发布流程客户端需要根据不同的运行环境编译生成不同版本的apk/ipa文件。1. 测试人员默认每天取前一天的最后一个版本测试；2. 测试已经通过的版本，测试人员发出通知，包括测试报告，版本号，测试结果等信息;3. 项目经理根据测试结果决定是否正式发布；4. 如果确定要发布，项目经理通知相关人员做好发布准备。a) 开发人员整理并提交 release noteb) CM创建发布基线c) 产品经理提交正式版本到电子市场5. 产品经理提交到电子市场后，邮件通知本次发布信息给相关部门相关人员。内容包括客户端发布的版本号,release note，可下载的电子市

28、场等。发布流程PMdeveloperCMTestUAT实施提交代码提出发布需求Release n ote通过构建系统通过build测试版本 存储空间安装部署文档1i卜 发布打基线T正式版本f存储空间卜实施（图未更新）422.服务端（php后台）的发布流程php程序不需要编译，发布和部署都是直接以文件的方式进行。服务端的发布围绕客户端进行，版本号与客 户端一致。测试版本的发布：指的是将开发验证过的代码从svn服务器上取出，部署到测试环境中去。正式版本的发布：指的是将测试验证通过的代码/文件，部署到正式环境中去。. 测试版本发布服务端的测试版本部署在测试环境（ ）下，需要客户端的测试

29、版本来配合测试，比如的版本，正式版本的测试 apk是，测试版本的测试 apk则是; 具体的过程如下描述：1. 开发人员提交代码到trunk主线，并将修改的文件列表提交给运维、CM。到release目录，按版本号存放；女口： 的存放路径是：;2. CM从对应的版本目录更新文件到测试环境；3. CM通知测试人员使用测试版本的客户端开始测试验证（网站的验证可直接在测试环境的目录下进行）；4. 测试验证过程，测试人员向bug系统提交bug,开发人员解决，转 bug处理流程；5. Bug解决后，再次验证通过，转正式发布流程4222正式版本发布正式版本部署在生产环境中，客户端的测试版本也相应的要变成正式环

30、境的版本。1. 测试版本测试通过之后，由测试人员出具测试报告、版本号，测试结果等信息；2 .发布工程师将通过测试的版本（文件列表）提交到正式环境（通过自动发布系统）；3. 测试人员（不限此类）做确认验证；4. CM创建发布基线（tags目录）；5. 转客户端的发布；6. 发布完成。4.2.3. 紧急情况发布对于生产环境出现的问题，为了修复紧急问题或为了快速响应新的需求，对应简单的修改需要忽略测试的环节,走紧急发布流程的情况，视为紧急情况发布。其流程如下：1.项目经理确定是否属紧急情况，必须要立即更新生产环境属于紧急情况的发布;2 .项目经理指定任务负责人，开发人员，DBA或者UI/UE;3.

31、任务负责人完成后直接联系发布工程师，部署到生产环境；4. 发布工程师将部署的文件备份，并通知 CM提交回SVN库的相关目录；5 . CM提交到SVN,并做补丁基线；5. 发布版本注释（release note ）无论是大版本，还是补丁、升级包的发布，都需要提供Release note需要包含以下主要内容:产品信息，包含软、硬件，子系统和模块，历史版本，源码路径，产品包路径等；实施部署的方案和步骤；版本关联的需求、任务、bug。对于产品发布版本管理，考虑采用wiki page系统进行管理6. 变更管理（待补充）7. 资源管理资源管理通过工具平台和权限手段将技术中心所有的资源有效的组织利用管理起来

32、，主要包括办公软件、开发和调试工具、公共文档、规范等，以及人员在工作中累积的经验（包括原创，收集的文档），实践过的优秀的工具等资源的分享与交流。通过资源的合理管理，不仅能提供一个标准有序的工作环境，提高工作效率。通过经验的分 享和交流还能对公司和个人的发展具有极大的推动作用。7.1. 提供统一的工作环境标准对于同类产品、项目相关需要建立一个统一的工作环境标准，所使用的工具、组件、技术采用相同版本，防止由于工作环境不统一所带来的不兼容等问题，提高工作效率。7.2. 文件共享（由信息部规划实现）在文件共享服务器（）上通过共享方式将办公软件、开发工具，调试工具等软件资源集中管理，保证资源的版本统一和

33、可用，并及时升级到更新的版本。确保让所有人员明确如何获取到所需的正确资源。7.3. 知识库建立知识库平台，将所有相关资料、众人的智慧和宝贵的经验通过文档，分享到知识库的平台，既能使大家获 取知识，提升个人能力，还能增加同事间的交流。目前我们用JSPwik i平台来实现这类共享。地址：Jspwiki 简介：Jspwiki是一个免费开源的知识管理系统，用于组织和共享文档。可以通过名称，内容，关键字等来搜索文档。有以下特点：1. 超文本格式的知识分享系统，支持中文;2. 可多人协作编辑，支持权限管理；3. 能保留网页每一次更动的版本，即使参与者将整个页面删掉，管理员也会可以从纪录中恢复最正确的页面版

34、本；4. 支持页面锁定：一些主要页面可以用锁定技术将内容锁定，其他人就不可再编辑了。5. 版本对比：WiKi站点的每个页面都有更新纪录，任意两个版本之间都可以进行对比，WiKi会自动找出他们的差另叽6. 更新描述：你在更新一个页面的时候可以在描述栏中写上几句话，如你更新内容的依据、或是跟管理员的对话 等。这样，管理员就知道你更新页面的情况。7. IP禁止：尽管 WiKi倡导人人都可参与，但如果有少部分恶意破坏者，WiKi有记录和封存IP的功能。8. Sa nd Box沙箱）测试：一般的WiKi都建有一个Sand Box的页面，这个页面就是专门用于让初次参与的人先到SandBox页面做测试，Sa

35、nd Box与普通页面是一样的，这里你可以任意涂鸦、随意测试。9. 编辑规则：任何一个开放的WiKi都有一个编辑规则，上面写明了大家建设维护WiKi站点的规则。没有规矩不成方圆的道理任何地方都是适用的。使用规范：1. Wiki更关内容不关心格式，所以我们更注重内容不必关心格式。2. 拥抱变化，接受共同频繁修改，群策群力，沉淀精华。3. 专题汇总研究并分享，适用于专题培训4. 页面用名字用英文（比如：ThisAPage）,这样移植方便。5. 不推荐大量转存互联网内容，请增加连接即可。6. 不推荐上传大量文件附件，如果需要请放到ftp或是SVN服务器，增加连接即可。8. 服务器规划1.服务器的规划

36、图服务器说明：因已有回新增服务器:共享同一服务器1,雨、提交获取源码譚源代码服务器 （svn、缺陷跟踪系统）获取源码构建服务器（持续集成）测试包 发布包 存储I Ir产品服务器知识服务器wiki知识库人测试环境测试服务器演示环境测试人员客服人员C/生产环境取获与享分所有人取获与享分部署服务器开发服务器测 自 员 人 发 开测试服务器员人试 试测 测示演品产 试测烟冒统系踪跟陷缺到3Q交提所有人员GO开发人员CJD测试人员现有服务器的使用情况（待整理）No地址型号cpu内 存硬 盘系统登陆132（新SVN服务器）Cetos 6.5x64Svn服务器Root/rootgolo216（旧svn服务器）Win 7VisualSvn服务器Admi