版本配置管理规范.docx

目 录1.概述21.1目标范围21.2定义21.3角色及职责21.3.1版本管理员21.3.2项目经理21.3.3开发人员21.3.4测试人员21.3.5测试部22.版本号管理规范22.1版本号规定22.2版本号变化基本原则22.2.1项目版本号变化22.2.2模块版本号变化22.2.3项目与模块版本号的一致性原则22.2.4版本号变化监管22.3模块补丁原则22.3.1适用范围22.3.2基本原则23.文档管理（提交）规范23.1模块文档23.1.1修改说明23.1.2配置说明23.1.3升级说明23.1.4编译及运行环境说明23.2全局文档24.数据库模块提交规范25.发布(归档)库管理规范25.1发布库结构25.2权限管理要求25.3发布库检查要求26.版本各过程管理规范26.1版本构建要求26.1.1构建脚本规则26.1.2构建任务要求26.2版本提交要求26.2.1提交内容26.2.2提交路径26.2.3提交检查26.3版本测试及回归要求26.3.1布署版本及冒烟测试26.3.2退回重新提交26.3.3回归测试及提交26.4版本发布/归档要求26.4.1归档内容26.4.2归档路径26.4.3归档说明2发布要求26.5版本备份要求26.6版本获取要求27.附录27.1附录：版本号编码规范及示例27.1.1版本号编码规范27.1.1项目版本号示例27.1.2补丁包及补丁编码示例27.2附录：源码归档规范27.2.1C工程目录设置：27.2.2JAVA工程目录设置：27.2.3WEB工程目录设置27.2.4版本号文件存放路径27.3附录配置库(SVN)结构及管理参考27.3.1总结构27.3.2配置项内容27.3.3配置项命名27.3.4配置项使用要求27.3.5配置库存放文件类型及大小规定27.3.6代码提交及获取要求27.4附录代码提交操作说明27.4.1操作方式一：项目的各模块在本地已经有关联的路径27.4.2操作方式二：项目的各模块在本地无关联的路径27.5附录版本构建操作说明27.5.1配置构建任务27.5.2版本正式构建2 概述本规定制定与实施目的是为了规范公司项目的版本管理，明确公司项目在版本规划、版本号确定、版本提交、版本测试、版本归档和版本发布等方面的流程和要求，以及研发体系在版本管理中的职责和配合关系等，保证版本管理的有序、高效进行，以及版本的存储正确、完整、安全和清晰等。1.1 目标范围n 规范流程、保证规划统一、保障版本安全、考核过程以及行为n 贯穿研发生命周期中的所有过程以及成果管理。1.2 定义本规范中涉及的术语为如下：项目、模块、补丁包及模块补丁；其中补丁包、模块补丁都发生在项目基础版本上线之后阶段。项目：利用有限的资源为客户完成包括业务解决方案定制、硬件设备安装、应用软件开发、维护服务等在内的系统集成工作，达到客户某一业务开展目标的一系列工作。模块：实现项目的特定功能的集合，是组成产品中的一部分，但它一般不能独立满足客户的需求。补丁包：指实现某一局部改良需求的而修改的软件成果的集合，它一般包括一个或多个模块和模块补丁。模块补丁：指针对某模块进行局部修订，并且不是以模块整体更新的方式，而是以修补的方式提供的修订成果。模块补丁通常使用在WEB或数据库模块中。 1.3 角色及职责版本管理过程参与的角色，包括研发部及测试部，各自在版本管理中的职责定义如下。1.3.1 版本管理员n 执行版本管理规定；调整版本库结构及控制权限；发现并及时向管理者反馈版本管理中的问题；目前版本管理员由测试部成员兼任。1.3.2 项目经理n 执行版本管理相关规定，解决版本管理过程中出现的问题；n 负责版本规划，明确版本的特性，确定版本开发计划和版本号等；n 负责版本自立项至版本发布的整个过程中项目组相关人员版本行为的指导和监督；n 负责检查归档版本的正确性、完整性、规范性。1.3.3 开发人员n 执行版本管理规定；n 按时提交版本，对提交版本的一致性、正确性、规范性负责；n 对版本开发过程中各自的中间工作成果的存储安全负责，确保工作成果不遗失、可追溯。1.3.4 测试人员n 执行版本管理规定、检查开发人员的提交版本，对检查结果负责；n 归档版本，对归档版本的一致性、正确性负责；n 发现并及时向管理者反馈版本管理中的问题。1.3.5 测试部n 建立、优化版本管理规定；n 解释、监督、检查版本管理规定的执行；n 审查项目组版本管理规定的执行情况和效果；n 收集管理规定执行过程中的问题、变更需求等，汇总并安排在适当时机对本规定进行修订完善。2. 版本号管理规范在项目开发启动阶段，项目经理根据项目需求和计划等，会同测试部制定开发版本的主/次/末版本号，明确版本特性，并向项目所开发和测试人员传达。版本规划可以在项目计划或设计等文档中体现。2.1 版本号规定所有版本编号采用统一方式：n 项目版本号编码方式：V主版本号.次版本号如：V1.0n 模块的版本号编码方式：V主版本号.次版本号.末版本号R发布版本号序号如：V1.0.1R0179101一个产品版本通常由多个模块组成，项目经理在确定版本编号时，模块版本号需要同产品版本号的“V主版本号.次版本号”保持一致，“末版本号+R发布版本号序号”则可据实际情况根据规范定义。详细的编码规范，请参照附录：版本号编码规范及示例。2.2 版本号变化基本原则版本号变化一般分为项目版本号变化及模块版本号变化2.2.1 项目版本号变化项目版本号变化，指的是主/次版本号的变化，仅在发生了系统级演进及功能级演进时，方可进行主、次版本号的变化。2.2.2 模块版本号变化模块主、次版本号随项目版本号的变化而变化；同时，如果项目发生了局部模块改良情况时，也可以进行模块版本号的变化，但仅限于末版本号的变化；即每次规划需发布（归档）一个局部改良版本，即需要对模块版本的未版本号进行升位。2.2.3 项目与模块版本号的一致性原则n 当一个项目中存在多个模块，且经过多次版本升级时，其各个模块版本号允许不一致；n 每次项目版本号需进行升位时，需同时对下属的各子模块主、次版本号进行升位；n 在已运行的项目中，新增加的独立模块，其版本号中的主、次版本号必须与项目版本号一致；n 对于已运行项目中，如存在子模块的主/次版本号与项目版本号不一致现象，后续对该模块进行升级发布时，需同时将主/次版本号升位到现有项目版本号一致。2.2.4 版本号变化监管n 由研发总工在文档设计评审时跟进各项目的版本号规划情况。2.3 模块补丁原则2.3.1 适用范围n 版本正式发布后或版本回归过程进行的少量缺陷修复，并且需要以修补的方式提供的修订成果的情况，如数据库编写的修订更新脚本、WEB个别页面或资源的更新等；2.3.2 基本原则n 模块补丁由于涉及变更内容较少，建议尽量采取部分更新升级的方式提交；3. 文档管理（提交）规范文档管理是版本配置管理中的重要部分，目前纳入管理的文档主要包括：需求文档、设计文档及数据库字典、用户文档（配置手册、用户手册）、验收文档（验收手册及其它手册）、模块文档（修改说明、升级说明、配置说明、环境布署说明）3.1 模块文档模块文档指与当前模块相关的修改说明、升级说明、配置说明、编译及运行说明，对于每个模块都应该存在这些内容信息。3.1.1 修改说明作为开发人员追朔版本的依据，也作为测试人员了解修改内容的依据。修改说明以追加的方式编写（如全新启动的项目，请以倒序排序）。内容要求如下：对于公共资源包的修改说明，需对当前版本与其它版本的兼容及依赖关系进行说明。3.1.2 配置说明配置说明作为各模块配置的依据，包括每个配置文件所在的位置及配置项的说明。每次涉及到配置项增加或修改，都必须更新配置说明，配置说明只保留最新的一份（与最新配置文件中的各需配置项一致），但配置说明杜绝为配置文件内容的COPY，而应为实际配置的指导。内容要求如下：3.1.3 升级说明作为版本升级的依据，以实际升级步骤为准，需考虑到不影响现网的配置文件、运行过程中生成的数据。每次版本发布都必须提供升级说明，以追加方式提供（如全新启动的项目，请以倒序排序）。，其中每次发布版本仅保留一次升级说明信息（即回归版本的升级说明应为修改，而非追加）。内容要求如下：n 每次提交的可执行程序所对应的文件夹结构必须一致，在确保此条件下，对应文件的升级写明为覆盖相应的文件夹内容即可；如涉及文件夹结构变化或需要先删除后更新时，则必须写明具体的路径；n 补丁升级如存在配置的变更，不允许以“覆盖文件、具体配置参照配置说明修改”方式来编写升级说明，而应详细说明哪个配置文件中增加什么样配置；注意，需注意文字“覆盖”、“替换”的正确使用。3.1.4 编译及运行环境说明说明编译需要的环境，包括编译环境版本、编译方法和步骤、依赖的公共资源和外部控件及其版本等。运行说明作为版本运行的依据；当涉及到编译或运行环境变更时，则需要更新编译及运行环境说明，内容要求如下：3.2 全局文档全局文档包括开发文档和用户文档等，如需求文档、设计文档、数据库字典、配置手册、操作手册等，都提交到与模块平级的全局文档目录下；全局文档的提交时间要求视不同版本而定；一般情况下，需求/设计类文档需随即将归档版本一起提交，以确保各文档资料的最新；用户类及验收类文档（如验收手册、操作手册等）可后补归档；详细包括：1. 需求文档：要求提供开发过程中被确认、细化和修正后的需求文档。其原始需求文档也作附件提交；暂不对文档格式作要求。2. 设计文档：要求提供开发过程中最终被确认的设计文档；3. 数据库字典：数据库字典也为全局文档，需提供与实际数据库相符的数据库字典；4. 配置手册：根据各产品的实际需要提供配置手册。配置手册要求对每个配置参数进行详细说明，需要对参数的缺省值、取值范围、配置指导原则、推荐配置等进行细致的说明。必要时还要按照一定的步骤进行描述，对需要配置的部分，能够突出显示。比如：以红色标注。对于比较复杂的配置，可以借助图片来说明。5. 用户/验收手册：要求提供完整的用户/验收手册，有关手册的编写要求请查阅相应的规范。4. 数据库模块提交规范数据库脚本提交相关要求如下：1. 数据库作为独立模块进行提交，版本号命名规则与工程模块一致；提交内容需要包括完整脚本、升级脚本、文档；其中升级脚本相当于工程模块的“可执行程序”，存放当次的升级脚本；完整脚本相当工程模块的“源码”，存放所有的数据库脚本，文档与工程模块一致；文件夹结构如下所示：源目录：提交目录：Build实例如下所示。2. 数据库脚本中，可按照脚本的执行特性来命名（建表、建库、建序列、初始化数据、建存储过程等）如下图所示：3. 修改说明、升级说明与3.1模块文档说明要求一样，同时升级说明中需注意要求：a) 执行工具和方式、权限（比如：请使用PLSQL/COMMAND方式/普通用户权限执行）；b) 执行脚本的顺序；4. 升级脚本中，必须在脚本中标明本次数据库的版本号，在注释部分指明该升级脚本是在哪一个版本基础上进行的修改；5. 在版本回归过程中，如涉及到数据库脚本存在变化，可灵活选用更新方式（直接修改上轮提交的脚本文件或新增加一个对上个脚本修订的文件），确保测试可回归以及现网正常升级即可。6. 数据库完整脚本仅供归档，测试不需验证正确性。5. 发布(归档)库管理规范当版本测试完成达到发布条件后，需将当前的版本归档到发布库；作为以后版本追溯的依据。发布库存放内容包括基线文档、测试通过的源码、可执行程序、发布说明文档5.1 发布库结构n 一级目录为项目名称。归档说明，放到此级下即可。n 二级目录类型（工程模块、全局文档、数据库脚本）。n 三级目录为发布版本日期（数据库脚本仍直接为版本号）。n 四级目录为具体的版本所有模块（包括工程模块、数据库脚本、本次对应的文档）。n 为了方便文档获取，文档除在对应的工程模块下进行归档后，同时在全局文档目录进行归档。5.2 权限管理要求版本发布后的版本位置为65发布库；为了发布库的安全，对权限管理要求如下： n 仅超级管理员具有发布库的所有权；n 非测试部成员仅有只读权限；n 测试部成员具有自己所负责项目的读写权限，其它项目的读权限；n 测试部指定人员每月必须检查权限情况，对于权限超出范围的权限，及时调整。5.3 发布库检查要求测试部成员、项目经理在日常工作中，有义务监督反映问题，由测试部安排人员进行跟进处理；1. 测试部需安排人员不定期对归档情况进行检查；针对检查情况不符合要求者，进行相应考核。2. 检查结果进行改进后，需再进行复检，以最终确保归档的有效性。6. 版本各过程管理规范6.1 版本构建要求6.1.1 构建脚本规则根据项目的情况，每个项目组都必须在版本提交之前做好构建脚本。1. 构建脚本 用于完整版本提交，其中产生的构建目录包括:可执行程序(完整)DOC源码(完整)，如下所示： 对于部分项目存在打补丁的情况时，需提供补丁构建版本，补丁构建脚本要求如下：补丁构建脚本；用于各个补丁版本提交；需注意每次提交时，需及时调整补丁构建脚本其中提交的内容包括：可执行程序(补丁)DOC源码(完整)2. 构建脚本规则l 构建发布路径必须使用$release.home，以确保所有项目发布的路径一致；l 数据库脚本需作为一个独立模块打包；l 客户端程序由开发自行打包提交，但同时需提供复制到发布路径的构建脚本；6.1.2 构建任务要求版本提交后，配置人员需要进行版本的构建。首次提交版本时，测试人员需要将构建任务设置为定时构建，以节约等待构建的时间；构建任务需注意检查如下内容：1. 确认构建的指向路径是否正确。2. 确认构建产出的版本路径是否正确，3. 确认构建产出的版本内容是否完整。4. 版本构建成功后，构建生成的版本存放地址为65构建库如版本多次构建不成功且反复找不到原因时（2小时内），版本构建人员有权打回版本并记一次提交问题。6.2 版本提交要求6.2.1 提交内容版本提交内容为SVN上指定的代码，且最后打包出来的内容包括可执行程序、源码（完整）、文档（请参考文档要求）。版本提交不要求必须按补丁或是按完整版本提交；但项目经理需确保按照升级说明的内容能正常完成版本升级；同时，为了避免后续环节不必要的工作量浪费，项目经理需合理控制版本的提交方式以及升级说明的有效性。6.2.2 提交路径版本提交路径为当前项目的tags/test/source/（补丁版本路径为：tags/test/source_pm），详细操作方式请查看附录；如tags/test/source下已经存在历史提交的版本，由提交人员进行删除即可；版本中的各模块非首次提交版本时，不能擅自修改提交路径，以避免自动构建失败而影响工作效率。6.2.3 提交检查版本提交责任主体为项目经理，项目经理对版本提交质量负责；故项目经理需检查提交的版本是否达到提交要求（例如内容是否齐全、版本路径是否正确、是否能正常打包等），当检查无问题后，项目经理方走OA流程通知测试接口人及其它人员；注意事项：客户端、数据库提交也是按模块提交方式一样，Build文件仅实现从SVN路径下获取到构建目录下。版本提交前如发现source存在上次版本的文件，请自行进行版本删除。6.3 版本测试及回归要求测试及回归过程中存在冒烟测试、打回、重新提交的相关事宜。6.3.1 布署版本及冒烟测试1. 测试人员接收版本署成功后，进行冒烟测试，如冒烟测试不通过（2小时内无法解决），测试人员可打回版本，并需要将事件以邮件的形式，通知测试部经理/项目经理及研发管理相关人员。2. 对于升级说明编写错误造成的版本无法正常运行问题，如问题及时解决，可不走版本打回流程，如果问题在2小时内仍无法解决，需走正式的版本打回流程。6.3.2 退回重新提交退回的版本再次提交时，版本号中的R发布版本号不需要改变，但只要是重新打包过的版本，序号就需要进行更新（如果退回版本隔天提交时，R发布版本号需要进行更新）。6.3.3 回归测试及提交回归测试版本的提交流程及接收标准，与正常提交流程相同。1. 回归测试过程中，版本的主、次、末版本号不能改变。如果特殊情况下需要改变，需要项目经理确认并通知对应的测试人员。2. 回归测试版本中的各模块文档内容，如升级说明有所变化，则修改升级说明的内容；修改说明为追加方式，不能混淆。6.4 版本发布/归档要求当版本测试完成达到发布条件时，由测试人员负责此版本的归档及发布；归档版本必须保证一致性、正确性、完整性。6.4.1 归档内容包括测试通过的打包文件（可执行程序doc源码）、数据库脚本、版本对应的最新的需求/设计及用户文档；同时： 执行程序归档：除了归档EXE外，还必须包含整个运行环境，如：配置文件，资源文件，附属目录等 源代码归档：必须保证源码能够正确编译；保证不将编译产生的中间文件、备份文件、临时文件，或者其他无效文件归入。 文档归档：为当前版本对应的最新文档归档。6.4.2 归档路径归档时，按发布（归档）库管理规范归档即可。注意保持目录结构的统一性。同时： 按模块的目录下，各模块补丁必须归为具体的模块文件夹下层。 当存在需求或设计资料且该版本对应一个以上模块时，文档必须独立于模块外归档；6.4.3 归档说明n 版本发布时，必须形成的完整的版本发布记录，以方便版本正常被获取；版本发布说明以追加方式编写。内容格式如下：n 注意：u 当存在文档归档时，对相关文档标识为有发布要求测试人员进行版本归档后，再将对应版本的可执行程序/文档发布给指定的用服人员；杜绝进行任何源码的发布。6.5 版本备份要求1. 每天定时自动进行SVN库完整备份；2. 每月初由测试部指定人员进行异地备份（包括SVN库及版本库），并交由总经办保管。6.6 版本获取要求当开发需要在已有历史项目版本的基础上进行开发时，需遵守如下要求：n 项目经理提要求与测试人员，由测试人员提供具体的版本地址信息与项目经理；n 开发人员必须从项目经理处获取版本相关信息，杜绝开发人员直接找测试人员获取版本的情况；n 如项目经理非从测试处获取源码者，由项目经理对源码的正确有效性负责。7. 附录7.1 附录：版本号编码规范及示例7.1.1 版本号编码规范所有版本编号采用统一方式：n 项目版本号编码方式：V主版本号.次版本号（如：V1.2）n 模块的版本号编码方式：V主版本号.次版本号末版本号R发布版本号序号（如：V1.2.1R0179101）一个产品版本通常由多个模块组成，在版本标号时，模块版本号需要同项目版本号在“V主版本号.次版本号”保持一致，“未版本号+R发布版本号序号”则可根据不同模块，灵活定义。主版本号：数字, 最大两位，不够两位，不必左补0次版本号：数字，最大三位，不够三位，不必左补0末版本号：数字，最大三位，不够三位，不必左补0发布版本号：数字，固定5位，左补0，以时间基础的算法计算而得序号： 数字，固定2位，左补0，依次累加发布版本号将以日期为基础，但不要用明显的日期表示，所以需要按照一定的规则计算，产生一个编号。并且根据这种规则，我们还能够将发布版本号还原得到日期。计算方法：发布版本号=YY*32*13+MM*32+DD（最大值37231）还原方法：YY=发布版本号/(32*13)MM=(发布版本号- (YY*32*13)/32DD =发布版本号- YY*32*13-MM*327.1.1 项目版本号示例项目版本号：版本号的前两位，即主版本号+次版本号；如：V1.1模块版本号：即主版本号的前三位，主版本号+次版本号+末版本号；如：V1.1.0项目版本号随项目主模块的版本号变化，每次主模块的主版本号或次版本号变化，则项目版本号随之变化；每次版本发布，如果主模块的主次版本号不变化，则项目版本号均为项目补丁版本号，项目补丁号按每次发布顺序编写，如第一次是001，第二次是002.依次类推。如：PM1.1N001例如：第一次发布版本：主版本：m1V1.0.0,m2V1.0.0，则项目版本号为：V1.0基线版本第二次发布版本：m1V1.0.1 则项目版本号：PM1.0N001第三次发布版本：m2V1.0.1 则项目版本号：PM1.0N002第四次发布版本：主版本为：m1V1.1.0 则项目版本号为：V1.1基线版本第五次发布版本：m2V1.1.0 则项目版本号为：PMV1.1N0017.1.2 补丁包及补丁编码示例补丁包编码规范：P+M+主.次版本号+N序号+D区号说明：P代表补丁包，M代表主次版本号；N代表第几个补丁包，PM1.1N001；代表V1.1版本的第一个补丁包；PM3.21N002D755；代表V3.21版本的第二个补丁包（深圳专有）；l 序号(N)：数字，最大三位，序列递增；l 对于专有补丁包，方需要增加D区号模块/数据库补丁编码示例：模块名+PM主次末版本号+N+序号+发布版本号Web_PM1.0.7N1R0179101；代表web端V1.0.7的第一个补丁Web_PM1.0.7N2 D755R0179101；代表web端V1.0.7的第二个补丁(深圳专有)Sql_PM1.0.7N2D755R0179101；代表数据库V1.0.7的第二个补丁（深圳专有）l 序号(N)：数字，最大三位，序列递增；不够3位，可不必左补07.2 附录：源码归档规范源码的归档比较复杂，规范如下：n 源文件必须完备源文件归档注意包括所有有效文件，包括子目录，源文件，工程文件，资源文件等等。n 设置工程的相关目录，不将中间文件归入版本库代码编译产生的中间文件，备份文件等无用文件，不归入版本库。要在项目的工程文件中设置中间文件的输出目录，具体设置如下。n 源码中使用到的第三方控件，将作为CODE的一部分，独立一个目录进行归档。目前VCL控件还需要进一步的整理，把不需要用到的控件版本清除掉，保证其归档控件最小；VCL也可以作为独立的公共资源进行管理，但在版本中，需要说明明确的存放路径，必须保证使用该资源时的正确性。n 归档目录组织源码归档目录可自行组织，但是必须能够完成编译。有些开发人员本地的开发目录同版本库目录不一致，而工程文件中通常保持有编译路径，这样导致从版本库中取得的版本不能编译，所有，要求开发人员本地目录要同版本库保持一致。下面内容对delphi，c+，java三种语言归档规范进行了简单的介绍，详细内容可参考培训资料库中的相关编程规范。7.2.1 C工程目录设置：n 归档目录结构参考： |模块名 |源代码和资源文件等|Output|模块名 |编译生成的中间文件|Release|模块名|可发布的执行文件输入文件的目录设置如下：（debug和release）n 归档源文件按照上述设置中间文件输入目录以后，项目目录下的自动生成的工程文件，源文件，配置、DLL、LIB、说明文件等都可归档。7.2.2 JAVA工程目录设置：n 归档目录结构参考： |src |源代码和资源文件等|build|编译的ant文件|lib|工程使用的lib |doc |工程相关文档|output |可执行程序输入目录|bin |.class编译输出文件n 归档源文件按照上述目录在eclipse的工程中建立目录，ant工程文件的使用参见java编程规范，bin目录下的文件不要归档，其他都需要归档。7.2.3 WEB工程目录设置n 开发目录结构参考：|src |源代码和资源文件等|buildjsp|编译JSP的ant文件与lib|doc |工程相关文档|WebRoot |WEB工程目录|work |编译JSP之后的.java,.class工作目录n WEB工程目录如下：|images |存放图片目录，可按图片功能划分，也可按WEB功能划分子目录|btn|banner|pic|include |存放包含文件，包括js,css,htc等|css|js|htc|META-INF|存放版本信息，说明信息等MANIFEST.MFcontext.xmlexception.jspversion.jsp|temp|存放临时文件目录，如上传的图片，文件等|images|update|WEB-INF |存放classes,jsp,lib,xml,等信息 |classes|jsp|lib|data|wap|conflg4j.xmlweb.xmlweb-config.xmlweb-message.xmlweb-model.xml|index.jsp 放置首页转发页注：所有的配置文件、jsp页面（转发的index.jsp除外）、数据文件必须放置在WEB-INF下，其中web.xml、web-config.xml、 web-message.xml、 web-model.xml必须放置在WEB-INF根目录下，其他文件放到相应的子目录下；如果没有对应的子目录，可自行创建子目录存放。7.2.4 版本号文件存放路径根据不同开发语言的工程目录设置规则，版本号需存放到不同路径下的版本文件中。1. JAVA类：版本号信息需存放到META-INFMANIFEST.MF文件中。2. .NET类：版本号信息需存放到PropertiesAssemblyInfo.cs文件中（最终形成为dll文件的版本号）。3. C+类：版本号信息一般存放到*.rc文件中，检查人员仅需检查可执行文件的文件属性中的产品版本号即可。7.3 附录配置库(SVN)结构及管理参考目前辅助管理工具为SVN，对应的配置库管理规范如下：7.3.1 总结构总共分Tag、Branches、trunk三个库，其中Tag为提交库，为研发向测试提交版本的存放空间、Branches为分支库，包括主干外的分支源码、项目资料；trunk则为项目主体开发库Tag库结构Tag下主要存放各模块的源码提交信息如下图所示：test下，source及source_pm下的目录结构与trunks下的source结构一致，source用于版本源码完整提交的临时存储；source_pm用于版本源码补丁提交的临时存储。Trunk/branchs 库项目资料结构项目资料包括项目过程中所涉及的所有项目信息，包括项目管理、需求、设计、原型、测试、用户文档等等；但原则上不包括现网工程相关信息（避免现网登录信息外泄）。Trunk/branchs库Src结构在trunk/branchs库中，以模块为目录，存放源程序。源程序目录结构请参照版本管理规范；同时数据库脚本作为与模块同级的目录块存在，每次提交的数据库脚本以版本号为二级目录。7.3.2 配置项内容目前SVN本配置项主要包括各阶段的文档、源码；包括但不限于如下：文档类研发过程中所产生的各类文档，过程文档和结果文档；比如各阶段评审记录、需求规划说明书、概要设计以测试报告、验收手册等等。代码类：自行开发模块源码、公共资可执行包（或必要的源码）7.3.3 配置项命名所有文档的管理纳入配置管理库，用版本控制工具进行统一管理。文档的版本控制主要通过文档的名称、文档控制页实现。 文档类配置项命名原则1、项目成果类文档命名方式：地区+项目简称+文档分类适用文档：项目开发计划，需求规格文档，技术方案文档，概要设计文档，数据库设计文档，配置手册，用户手册，验收手册等。地区：可选，主要用于该产品属于多个项目时进行的标识。项目简称：必填，表现所属哪个项目。文档分类：必填，表现当前文档所属的类型示 例：广西日志管理平台需求规格说明书.doc2、项目过程监控类文档命名方式：项目简称+文档分类适用文档：过程跟进表、评审意见表单示 例：广西日志管理平台评审会议纪要20120817.xls代码类命名原则：参照版本管理规范7.3.4 配置项使用要求1) 开发人员每次修改，或者新增、删除、拷贝工作区对象后，应该立刻提交到版本库，有效保持工作区与配置库的高度一致；2) 开发人员在每次修改工作区中代码或者文档时，首先更新该对象，可以尽量减少冲突、合并；3) 开发人员确保每天下班之前进行一次配置项的Update；4) 保证提交到的版本库的代码没有BUG以免影响开发组，可以适当利用加锁机制，减少冲突；5) 保证各文档的最新版本及时提交至SVN.7.3.5 配置库存放文件类型及大小规定u 文件名及目录规定：按照配置库结构及配置项命名规则进行命名；u 文件大小规定：建议最大不超过20