上海大众平台管理规范.docx

《上海大众平台管理规范.docx》由会员分享，可在线阅读，更多相关《上海大众平台管理规范.docx（24页珍藏版）》请在第一文库网上搜索。

1、上海大众汽车SHANGHAI VOLKSWAGEN上海大众Java应用平台项目平台管理规范Platform Management Specification当前版本：版本号V 修改日期： 二文档状态：正式作者：上海大众项目组文档OARP序号分类姓名范围要求1Owner曹宗伟2作者曹宗伟3审核人4审核人5审核人6批准人文档修订记录序号版本号修订日期修订概述修订人审核人批准人备注10.12014-07-04编写文档曹宗伟231平台版本管理1.1 目的定义平台和组件版本管理规则，统一平台版本标识、版本升级和版本定义规则。1.2 适用范围上海大众自主建设平台，如Java基础应用平台。上海大众自主建设组

2、件，如应用框架组件、甘特图组件。1.3 平台版本标识1.3.1 平台版本标识版本标识方法:平台简称主版本号. 副版本号. 小版本号主版本号：同一主版本号平台必须向下保证兼容性，如XXXI. 3. 1必须兼容XXXI. 1. 2,在有重大技术变更或升级时，可变更主版本号，如Spring技术升级或增加移动开发支持。主版本号变更时，应当提供升级指南或升级工具。.副版本号：副版本号代表一个平台研发项目或修复一组bug之后的稳定版本，副版本号的变更可以提供新特性，但必须保证向下兼容性。.小版本号：项目组内部发布版本号，如预览版本1,预览版2,直至稳定版本。.版本标识实例： XXX 1.0 (XXX平台的

3、1.0大版本，小版本号为0时，可以省略，但副版本号不能省略) XXX2.2. 1(基于XXX2.2增加了小部分功能的平台小版本,无新模块增加)1.3.2平台发布版本标识 平台发布版本标识：平台版本标识(Build#) Build号代表平台编译次数 平台发布版本实例：.XXXI. 2. 1 (Build5662) XXX2. 1. 11 (Buildl399)1.4 平台版本升级规则平台立项时，必需先确定本次立项计划发布的主、副版本号。1.4.1 主版本号升级规则 新平台立项，主版本号为1; 平台的主体构件进行重大修改，主版本号加1; 平台的主体构件之间的接口协议修改，主版本号加1;.平台开发+

4、平台测试的工作量大于200人月的平台版本开发，主版本号加1;.主版本号建立或变更时，副版本号同时置0。1.4.2 副版本号升级 新平台立项，副版本号为0；.为处理平台Bug,对现有功能模块做重大修改，副版本号加1； 改进现有功能模块，不增加新的功能模块，平台的主体构件未做重大修改，副版本号加1; 为增加平台功能，在原版本平台上增加新的功能模块，而平台的主体构件未做重大修改，并且平台的主体构件之间的接口协议也未做修改，副版本号加1; 平台开发+平台测试的工作量在50200人月之间的平台版本开发，副版本号加1; 当主版本号变更时，副版本号同时置0。1.4.3 第三位版本升级规则（小版本号） 新平台

5、立项，小版本号为0; 副版本号增加1,小版本号置0； 为修改程序中的Bug并发布补丁，Release号加1； Release号超过到一定数以上，可根据情况，升级副版本号，同时Release号置零。1.5 平台发布版本定义1.5.1 试用版1 .版本发布目标a.模拟用户实际运行环境和用户实际操作场景，验证和评价平台的的功能、可用性、可靠性、性能等的表现和可接受度。b.验证平台功能是否真正符合用户需求2 .适用版本a.平台大版本，比如1.0, 1. 1, 1.2；b.全新平台大版本；C.平台的架构发生了较大变化d.平台的特性作了重大修改e.平台代码作了大规模重构f.平台的安装和使用方式发生了较大变

6、化。3 .发布标准a.平台版本平台功能基本完备，经过一轮系统测试，平台集成完成,发现的致命和严重BUG全部修改，版本相对稳定;b.验证平台可用性的典型用户场景已经准备完成。4 .过程任务a.组织内部人员，根据平台定位和用户场景进行平台的试用；b.评价平台在可用性、可靠性、性能等方面的表现;C.对重大的可用性、可靠性、性能问题进行修改。1.5.2正式版1 .版本发布目标a.支撑使用平台开发应用b.在真实环境中，检验平台运行状况（质量、性能、稳定性、可用性）2 .适用版本a.平台发布小版本,比如1.0 . 1, 2. 1. IE3 .发布标准a.平台经过全面测试，没有遗留影响用户使用的问题。b.平

7、台功能已经完备，可以解决用户需求；c.平台质量已经相当稳定和可靠；出支持响应渠道畅通，响应速度满足大规模用户要求；e.平台的基本文档已经完备。4 .过程任务a.建立进行培训和平台支持体系，及时解决平台使用中的问题；b.建立反馈体系，收集平台功能、问题和需求;2源代码库管理2.1概述本章主要描述关于在多平台并行开发过程中，如何进行源代码的规范化管理，主要内容包括：平台源代码库管理和小补丁源代码管理规范。目标读者：配置管理人员、项目经理、开发人员2.2 使用范围适用于基础平台、组件、平台补丁。2.3 源代码管理总体策略技术组件（技术平台）源代码独立SVN库;平台按大版本建立独立的源代码SVN库，每

8、个版本基于技术组件进行扩展开发，并发布平台基线版本；层次化的平台源代码管理结构：2.4 源代码建库流程革新性技术升级或开发新平台时 需要建立新的代码库，建立代码库需要向配置管理负责人申请建立代码库，申请单请参考上海大众代码库管理代码库申请单。2.5 平台源代码建库规范2.5.1 技术组件源代码库.技术组件库独立SVN库进行管理，包括源代码和文档，具体见技术组件管理章节。2.5.2 平台源代码建库规则.总体原则：每个平台建立独立的基于技术平台扩展开发的源代码SVN库。原则上一个系列的平台源代码复用一个SVN库，平台架构发生调整情况下，建立新的SVN库，并迁移代码，迁移成功标志为日编译通过，BVT

9、用例通过，否则不可在新SVN进行新代码开发。命名规则：平台名称+大版本号库名实例：XXXI.基于大版本的升级版本需沿用原有大版本的SVN库，除非平台架构发生变更，代码需要完全重构，需要重新创建源代码SVN库。2.6 源代码SVN目录结构SVN源代码目录结构规范如下，一级目录、二级目录必须执行,三级目录推荐执行。SVNroot/库名|developI I build （平台编译脚本）IL二级模块AI 二级模块BIL.src（核心代码，下级目录建议按照平台2级模块建立）I| _二级模块A如（Server）I二级模块 B 如（Studio）test（测试）litest （集成测试,必选）I二级模块A

10、I二级模块BIptest （性能测试,必选）I二级模块AI二级模块BIctest （兼容测试,可选）二级模块A二级模块Bworkdir （临时工作目录）dev 1 （按开发人员的邮件名建立子目录，例如，chengy）2.7 小补丁源代码管理2.7.1 小补丁版本命名规则.小补丁版本号命名规则：相应平台的版本号发布日期（yyyyMMdd） +P+序号（1, 2, 3.） 例如：XXX_1. 1. 10_20150312_Pl, XXX_1. 1. 10_20150312_P2说明：平台补丁必须同时提交进入平台的源码SVN库中。2.7.2 小补丁源代码配置库规范建库总体原则：统一使用一个小补丁的S

11、VN管理库.平台和OEM平台需将小补丁纳入到此SVN进行管理，并遵循小补丁管理规范。.目录结构规范:SVNroot/PATCH|_xxx1Lxxxi （大版本号）11发布的平台号（如XXX.1.3）|Lpatchl (如 XXX.L 3 20150312 C1)1_src （源文件）_dist（结果文件编译后的提交物)_readme. txt|_XXX21发布的平台号（如XXX_2.3.5）3 Tag和分支管理平台版本、标签和分支关系图如下：平台发布版本必须打标签，标签名必须符合TAG规范；平台大版本变动必须建立分支，新版本使用主干代码库，老版本使用分支代码库。XXX平台版本、标签和分支关系图

12、2.5.23.1 TAG规范3.1.1 TAG建立标准TAG标识基线版本，任何平台和技术组件的基线版本发布时，必须打基线版本TAG；基线TAG需要由配置管理员来完成，必需符合TAG命名规范。3.1.2 TAG建立流程1.项目需要打TAG则由项目负责人发邮件通知给配置管理员，邮件要求如下： 发件人：项目负责人收件人：配置管理员 抄送：XXX 邮件正文：参考上海大众代码库管理-标签申请单2.配置管理员打完TAG并自我验证后，立即邮件反馈给项目负责人,并告知打出来的TAG名称；3.1.3 技术组件TAG命名规范技术组件分支/TAG命名规范参见技术组件管理组件TAG规范。3.1.4 平台TAG命名规范

13、 TAG命名规则：平台名称+发布版本号（按平台发布版本号到第3 位）+RELEASE/BASELINE+发布时间yyyyMMddhhmm_BuildNumber,若此版本正式发布，则使用RELEASE；若此版本为内部里程碑版本或中间交付版本，但不正式对外发布，则使用BASELINE。.正式发布版本TAG名示例：.XXXI. 0. 3 版本 TAG 名：XXX103 RELEASE 201503122200 BUILD1278；中间基线版本TAG名示例.XXXI. 0. 3中间基线版本TAG名：XXXI. 0. 3_BASELlNE_201503122200_BUILD1001；3.2分支规范3

14、.2.1 分支建立原则1 .平台启动大版本项目时，需要建立分支，主干版本为新的大版本代码库，而分支则作为上个大版本代码库；2 .分支控制在平台版本级别，需要建立分支时，对整个平台版本的所有代码打上统一的分支名；3 .分支建立后，基线版本维护基于分支维护，补丁验证通过后，代码同步合并到主干版本代码中；4分支建立统一由项目负责人（或维护负责人）申请，配置管理员统一建立。322分支命名规范1 .维护分支：平台名+版本号（到3位）+SP2 .维护分支示例：a. XXXL 1版本的维护分支:XXXI10SPb. XXX2. 1.2版本的维护分支:XXX620SP3 .特殊版本分支（根据需要）：版本英文名+版本号+”特殊版本标识“3.2.3分支建立流程1.项目需要打分支则由项目负责人发邮件通知给配置管理员，邮件要求如下:.发件人：项目负责人