最新软件版本控制流程.pdf
软件研发中的版本控制与发布流程

软件研发中的版本控制与发布流程在软件研发过程中,版本控制与发布流程是确保软件开发高效、无缝协作的重要环节。
版本控制系统能够帮助团队成员协同工作,减少冲突,提高开发效率。
而发布流程能够确保软件的质量和稳定性,满足用户需求。
本文将介绍软件研发中常用的版本控制工具以及发布流程,旨在帮助读者更好地理解软件开发过程中的版本控制与发布管理。
一、版本控制工具的选择与使用1.1 分布式版本控制系统分布式版本控制系统(Distributed Version Control System,简称DVCS)在软件研发中得到普遍应用,与传统的集中式版本控制系统相比,它具有更强的分支功能和更高的灵活性。
常见的DVCS工具有Git和Mercurial。
Git是目前最受欢迎的分布式版本控制系统,其强大的分支功能使得团队成员可以并行开发不同的功能模块,避免冲突,并能够轻松地合并代码。
Git还提供了详细的日志记录和代码审查功能,帮助团队成员更好地跟踪代码变动和进行代码质量控制。
Mercurial也是一款功能强大的分布式版本控制系统,与Git相比,其界面更加直观友好,学习曲线较为平缓。
如果团队成员对分布式版本控制系统不够熟悉,Mercurial可以作为一个良好的选择。
1.2 集中式版本控制系统集中式版本控制系统(Centralized Version Control System,简称CVCS)是传统的版本控制系统,其核心是一个中央服务器存储代码库,团队成员通过与服务器进行交互来进行版本控制。
常见的CVCS工具有Subversion(SVN)和Perforce。
SVN是一款流行的集中式版本控制系统,相比起Git,它更加适合小规模团队的协作开发。
SVN可以很好地管理代码的历史记录和变更,提供了方便的回滚和文件差异比较功能。
Perforce是一款商业化的版本控制系统,适用于大规模软件研发项目。
它具有高度可扩展性和强大的分支功能,能够满足复杂项目的版本控制需求。
软件版本控制流程

软件版本控制流程1. 创建软件仓库:首先,需要在版本控制系统中创建一个用于存储软件版本的仓库。
仓库可以是本地的,也可以是分布式的,如Git、SVN 等。
2.初始化仓库:创建仓库后,需要对其进行初始化,即将其配置为可用于版本控制的状态。
这包括定义仓库的文件结构、设置权限、配置用户访问权限等。
3.创建分支:软件开发过程中常常需要创建不同的分支来开展不同的任务。
分支可以是主分支、开发分支、测试分支等。
分支可以在需要的时候创建,也可以根据需求进行合并和删除。
4.提交变更:在软件开发过程中,团队成员会对软件进行变更,如添加新功能、修复错误、优化性能等。
在每次变更之后,团队成员需要将变更提交到版本控制系统中。
5.合并变更:当多个团队成员同时对同一文件进行变更时,会产生冲突。
在这种情况下,需要进行变更的合并,以确保不同团队成员的变更能够协调一致。
6.回滚版本:在一些情况下,需要回滚到先前的版本。
回滚版本可以通过撤销最新的变更或切换到之前的版本来实现。
7.标记版本:为了能够标识和追踪软件的不同版本,可以对特定的版本进行标记。
标记可以基于时间、功能、修复等进行命名,以便于进行回溯和追踪。
8.发布版本:当软件开发到一定阶段时,通常需要将其发布给用户使用。
发布版本可以通过打包、部署等方式实现,并记录在版本控制系统中。
9.更新和维护:软件发布后,可能会出现用户反馈的问题或新的需求。
在这种情况下,需要对软件进行更新和维护。
更新可以通过创建新的分支或从先前的版本进行修复来实现。
总体而言,软件版本控制是软件开发过程中不可或缺的一部分,它可以帮助团队成员更好地协同工作、管理变更和追踪版本。
通过有效的版本控制流程,可以保证软件的稳定性和可靠性,并提高开发效率和团队协作能力。
(完整版)软件版本管理办法

广东亿迅科技有限公司软件版本管理办法(暂行)第一章总则第一条为了加强广东亿迅科技有限公司(以下简称“公司”)的软件版本管理工作,进一步细化公司配置管理规范,建立软件版本管理的规范化操作流程,保证公司软件产品质量,制定本办法。
第二条本办法适用于公司各技术部门的软件版本管理工作。
第三条本办法所称的软件版本是指公司所有面向用户发布的应用软件版本。
第四条软件版本(以下简称“版本”)管理应遵循以下原则:(一)实施版本变更应符合以下原则之一:1.为满足客户新业务、新功能需求;2.为满足提高业务质量、提升业务性能指标和容量扩充的需求;3.为解决软件故障和软件稳定性、安全性、可控性问题;4.为了提高软件可维护性。
(二)版本的集成和发布应严格按照计划执行,避免随意和频繁更新版本;(三)为保证软件质量,任何一个软件版本须通过版本测试后方可上线;(四)公司所有软件版本必须通过正式渠道发布给用户,未经审批各部门和个人不得擅自向用户发布软件版本。
第五条版本管理是保障应用软件正常运行的一个重要手段,各相关部门应认真贯彻落实,并纳入工作考核;未按本办法执行从而造成版本故障影响用户正常生产的,一经发现将追究其相应责任。
第二章职责与分工第六条版本管理实行总体质量控制,分级实施管理原则,管理工作涉及版本质量管控部门和版本集成发布部门;质量管理部是版本质量管控部门,各业务部门是版本集成发布部门。
第七条版本质量管控部门的工作职责如下:(一)负责制定与版本管理工作相关的管理办法和工作流程并组织落实;(二)负责组织版本管理相关的培训并提供技术支持;(三)负责跟踪和监督公司版本管理工作的执行情况,协调解决执行中的问题,并对版本管理的执行效果进行评估考核;(四)负责组织和实施对版本的测试验证工作;(五)负责对版本升级实施效果和版本质量进行监控和评估;(六)其它应由版本质量管控部门负责的事项。
第八条版本集成发布部门的工作职责如下:(一)负责本部门版本研发集成工作环境的建立、维护和管理;(二)负责依据版本管理工作流程,执行版本开发、集成、发布及维护的相关工作;(三)负责收集分析业务需求,制定版本计划并按计划组织实施;(四)负责跟踪版本上线后的运行情况,收集用户使用的反馈信息,改进版本质量;(五)其它应由版本集成发布部门负责的事项。
软件开发版本控制规范详解

软件开发版本控制规范详解在软件开发过程中,版本控制是非常重要的一环。
它能够帮助开发团队有效地协同工作、管理代码及项目的变更。
本文将详细介绍软件开发版本控制的规范,包括命名规则、分支管理、代码审核以及发布流程等内容。
一、命名规则在版本控制中,合理的命名规则能够使开发人员快速识别和定位不同的版本。
下面是一些常用的命名规则示例:1. 主版本号(Major Version).次版本号(Minor Version).修订号(Revision Number):例如1.0.0。
2. 年份.月份.修订号:例如2023.09.01。
3. 使用语义化版本(Semantic Versioning):例如v1.0.0-alpha.1。
团队可根据实际需要选择适合自己的命名规则,但需要确保团队成员之间的统一和沟通畅通。
二、分支管理有效的分支管理可以帮助团队并行开发不同的功能和修复bug,同时减少代码冲突的发生。
下面是一些常用的分支管理策略:1. 主分支(Master):用来保存稳定的正式版本,只能从其他分支合并,不能直接在该分支上修改代码。
2. 开发分支(Develop):用来集成各个开发人员的代码,是日常开发工作的主要分支。
3. 功能分支(Feature):用来开发新功能的分支,从开发分支上创建,开发完成后合并回开发分支。
4. 修复分支(Bugfix):用来修复线上问题的分支,从主分支上创建,修复完成后合并回主分支和开发分支。
5. 发布分支(Release):用来准备发布正式版本的分支,从开发分支上创建,进行代码审核、打包、测试等工作,完成后合并回主分支。
团队可根据具体项目和团队规模选择适合的分支管理策略,并在团队中建立相应的分支管理流程。
三、代码审核代码审核是保证软件质量的重要环节,它能够发现和纠正潜在的问题,提升代码的可维护性。
下面是一些常用的代码审核规范:1. 代码静态分析工具:使用静态代码分析工具,如Lint、SonarQube等,对代码进行自动检查,并根据检查结果进行修改。
版本控制工具的工作流程与实践(三)

版本控制工具的工作流程与实践随着软件开发的日益复杂化,团队协作成为了一个巨大的挑战。
在多人协作的过程中,版本控制工具成为必不可少的工具之一。
版本控制工具不仅能够记录代码的变更历史,还能够协助团队成员之间的合作与沟通。
本文将探讨版本控制工具的工作流程与实践,帮助读者更好地理解并应用版本控制工具。
一、版本控制的基本概念版本控制是一种管理软件代码变更历史的方式。
它可以追踪每一次代码的修改,记录下修改的内容、时间和负责人等信息。
通过版本控制工具,我们可以随时查看代码的演进历史,对不同版本进行比较,还能够进行代码的合并与分支操作。
二、集中式版本控制和分布式版本控制在版本控制工具中,存在两种主要的工作流程模式:集中式版本控制和分布式版本控制。
1. 集中式版本控制集中式版本控制工具通过一个集中的服务器来存储代码的所有版本,所有的团队成员都需要连接到该服务器来进行开发。
常见的集中式版本控制工具有SVN(Subversion)和Perforce等。
团队成员需要从服务器上获取最新的代码,进行修改后再提交到服务器上。
2. 分布式版本控制与集中式版本控制不同,分布式版本控制工具在每个团队成员的本地都拥有全部代码的完整副本,不需要连接到服务器。
分布式版本控制工具如Git和Mercurial等,可以在离线情况下进行代码的修改、提交等操作。
团队成员可以在本地进行开发,最后再将代码推送到服务器上。
三、版本控制工具的使用实践版本控制工具的使用实践对于团队协作非常重要。
以下为几个使用版本控制工具的实践建议:1. 常备分支与主分支为了保持代码的稳定与安全,在使用版本控制工具时,我们可以创建一个主分支和若干个常备分支。
主分支用于存放稳定的代码版本,只有经过测试和审查后的代码才能合并到主分支上。
而常备分支可以用于开发和测试等环节,团队成员可以在常备分支上进行自由的代码修改和提交。
2. 命名规范与注释规范在使用版本控制工具时,良好的命名规范和注释规范能够提高代码的可读性和可维护性。
软件开发中的版本控制与发布

软件开发中的版本控制与发布在软件开发过程中,版本控制和发布是非常重要的环节。
通过版本控制,开发团队可以管理和跟踪软件的变化,包括 bug 修复、新功能开发、代码优化等。
而发布则是将开发完成的软件交付给用户使用。
本文将介绍软件开发中的版本控制与发布相关的内容。
一、版本控制版本控制是软件开发中的重要环节,它用于管理和跟踪软件的变化。
“版本”指的是软件的不同状态,包括修改、添加或删除的功能、 bug修复等。
版本控制系统记录并追踪这些变化,以便开发团队在必要时进行查看、恢复或合并代码。
1.1 分布式版本控制系统分布式版本控制系统(Distributed Version Control System,DVCS)是一种常见的版本控制系统,其中最著名的是 Git。
与传统的集中式版本控制系统(Centralized Version Control System,CVCS)相比,DVCS 允许开发者在本地存储完整的代码仓库副本,并可以在没有网络连接的情况下进行工作。
这样的设计使得分布式版本控制系统更加灵活和高效。
1.2 版本控制工作流程在软件开发过程中,采用适当的版本控制工作流程有助于协作和管理代码。
首先,开发者从代码仓库中克隆(clone)一个副本到本地开发环境。
然后,在本地进行修改,包括添加新功能、修复 bug、代码重构等。
每次开发者完成一个功能或 bug 修复,都可以将修改提交(commit)到本地代码仓库。
提交时,可以描述一些有关所做修改的备注信息,以便日后查看。
当需要与其他开发者协作时,可以将本地的修改推送(push)到共享的代码仓库。
其他开发者可以拉取(pull)最新的变更到本地,合并(merge)修改并解决冲突(conflict)后,进行继续开发。
1.3 分支管理分支(branch)是版本控制中常用的概念。
通过创建分支,开发者可以在独立的环境中进行功能开发、修复 bug 等工作。
同时,其他开发人员仍可在主分支(master)上继续开发。
软件版本管理规范最新版本

软件版本管理规范第一章目的本规范详细规定软件项目版本管理的对象、存储目录、分支、权限、维护等内容,使软件项目版本管理流程化并规范化,确保在系统开辟和实施过程中项目的完整性和一致性。
1. 第二章合用范围所有系统开辟及实施项目的软件项目都应进行版本管理。
项目中所有正式文档和代码都应纳入配置库(可使用工具建立配置库,本文所述使用的是 SVN )进行版本管理。
2. 第三章职责配置库管理员:负责配置库的日常维护和管理;监督开辟及测试部门及时提交版本管理对象(即配置项)。
此岗位可由开辟或者测试人员兼任。
3. 第四章内容4.1. 版本管理对象包括但不限于:项目总体计划可行性研究报告开辟计划需求说明书需求设计原型设计说明书系统开辟变更申请单系统管理手册用户操作手册培训计划培训记录源程序支持系统运行的配置文件存储过程脚本测试计划测试用例测试脚本测试报告上线计划上线申请版本维护日志4.2. 配置库的目录结构每一个项目在配置库中应拥有惟一的项目名称。
配置库目录结构与项目内部的目录结构建议按下列格式创建。
配置库目录结构规划:┠tags(发布)┃├v1.0.0_T1_2022909┃ ├v1.0.0.33899_T1_20221009┃├v1.0.0_R1_20221109┃├v1.1.0_T1_20220229┃└v1.1.0_R1_20220229┠trunk(主版本)┃└projectA┃ ├sr c┃├ MY_MOOC┃ ├do c┃ ├too l┃├。
┖branches(分支)├SY_ABC├TJ_ABC├WH_MOOC其中,项目内部的目录结构:|– projectA|–src (保存该项目的源程序)|–doc (保存项目相关文档)|–000.项目管理 (保存项目过程管理相关文档)|–010.项目计划 (保存项目计划相关文档)|–020.项目需求 (保存项目需求相关文档)|–030.系统设计 (保存项目设计相关文档)|–030.系统测试 (保存项目代码测试相关文档)|–040.系统实施 (保存项目部署实施相关文档)|–050.系统运维 (保存项目运维文档,包括培训、用户手册等)|–060.技术资料 (保存项目技术文档,包括第三方技术资料等)|–。
软件版本控制办法

软件版本控制办法1目的规范公司软件产品版本升级流程,清晰管理版本号,加强不同版本软件保存的可靠性。
2适用范围适用于研发结束进行测试或投入应用的硬件驱动软件或独立工作软件,已销售产品中的软件系统的升级或变更管理。
3 职责3.1 版本管理员负责统计公司内所有软件的版本信息,管理软件版本号,向软件工程师传达工程及销售人员反馈的软件问题并进行汇总,并在软件升级结束后向系统集成工程师提供新版本的软件系统。
3.2 项目软件负责人及软件工程师负责对软件系统进行升级,项目软件负责人负责将升级后的软件上传到公司产品服务器,并通知版本管理员记录升级信息。
3.3 每个项目的软件负责人对本小组内目前完成测试的软件及系统进行归档和版本维护。
3.4 项目软件负责人对本项目的软件升级方法进行确认,将对软件的整体调整与总工协商后确定方法。
3.5 销售人员和工程人员向版本管理员通报软件产品问题,工程人员负责升级后软件的重新安装和使用跟踪,并对修改版本软件的使用情况在规定时间内进行反馈。
3.6 工程部集成工程师在完成软件安装后应填写客户版本信息清单,提交版本管理员进行归档并汇总。
3.7 对于软件系统的一般性 BUG 和软件实现明显不适当的问题,项目软件负责人应积极进行修改,升级软件版本;其他软件使用性问题,项目软件负责人有权确定是否修改。
3.8 对于软件功能性的重大修改,应将问题进行备案,并提交总工程师确定是否修改以及修改时间。
对涉及需要产品升级等问题时,应提交公司技术委员会进行讨论确定。
4 工作程序4.1 软件系统保存4.1.1 建立公司产品存储服务器,网管为每个项目组分配源代码存储区域,对每个项目组的软件归档负责人分配相应文件夹的写一次及可读控制权限,本组人员对该文件夹具有上传和只读权限,其他人员不能浏览该文件夹内容。
网管为源代码生成的应用程序建立存储区域并对公司内部人员分配权限。
4.1.2 项目组软件负责人将本项目组内现有的全部源代码及应用程序上传到软件服务器的相应区域,并填写《版本信息清单》,交版本管理员保存。
- 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
求部门提供;
2010/01/01
A/2
公司组织机构调整; 应用 XX
XX
开发部与产品研发部合
并为 “软件研发部” ,进
行相关修改; 比如编制部
门、发放范围
2011/02/23
A/3
调整了流程; 修改了版本 XX
XX
号定义、 入库流程; 增加
了版本号变更流程、 适用
范围、 三个附录表单 (程
序源码版本号列表、 部署
d) 产品经理: 填写《新产品研发立项审批表》 ,提交产品中心总监审批。经审批通过后,
定义产品升级版本号给产品开发经理和配置管理员。
产品新版本研发完成经质量保证
部批准发布后,申请入产品库,填写《产品入库申请单》给配置管理员。
e) 产品中心总监: 批准产品升级申请。
2.2.2.3.产品新版本研发测试:
版本号列表、 新产品升级
立项审批表);
编制部门: 研发中心 发放范围:项目管理部、 研发中心、产品中心、 系统网络部、质量保证部、运营维护部、商务部
北京万度网络科技有限公司作业文件
万度
软件版本控制流程
1. 目的
主要针对软件版本的控制,以确保公司资产得到保护。
2. 流程
流程共分为版本号定义、版本号变更、入库流程、出库流程、产品列表流程五个部分。
初始化文件、 BMS 菜单列表、割接方案)
设计文档 (概要设计、 详细设计、 数据库设计) □
操作手册
□
源代码
□
测试报告
□
项目管理文档 (会议纪要、 立项审批、 项目周 □ 报)
参考资料
□
其他
□
说明:如果需要需求规格说明书、概要设计书、详细设计、数据库设计、源代码等之一需要总监签 字。
北京万度网络科技有限公司作业文件
参与角色 :项目经理、产品开发经理、产品经理、测试经理、配置管理员、质量保证部经理、研发 中心总监
版本变更发起方 :项目经理、产品开发经理、产品经理; 使用工具 :版本控制工具 CVS、SVN、VSS;
2.2.2. 主要活动
2.2.2.1 发起产品版本变更:
a) 项目经理: 根据项目需求提出产品升级 ,要求给产品开发经理。
版本
说明
作者
附录Ⅱ
版本出库申请单
编号: YHXX-ZLJL-171
项目编号
需求名称
出库产品
名称
出库原因 (申请原因) 入库时间或
说明
版本说明
出库申请人:
对表操作 SQL语句 表结构及索引说明
部门 / 总监:
编号: 版本号
配置管理员:Βιβλιοθήκη 日期:年 月 日 日期:
年月 日
单 清 档 文 产品资料(产品策略书、 word 版本、 PPT)
b) 产品开发经理: 修复产品原有版本的缺陷或满足项目需求,填写《新产品研发立项审 批表》给产品经理。
c) 产品经理: 产品经理根据市场需求或其他部门反馈意见, 产品研发立项审批表》 ,提交产品中心总监审批。
提出产品升级要求, 填写《新
北京万度网络科技有限公司作业文件
万度
2.2.2.2.产品版本变更审批:
日期: □
年月 日
北京万度网络科技有限公司作业文件
万度
部署包(执行代码、部署文档、初始化
□ SQL、
初始化文件、 BMS 菜单列表、割接方案)
需求文档(需求规格说明书、功能列表)
□
业务策划
□
评审报告(页面评审、需求评审、策划评审、
□
原型评审、概要设计评审、数据库设计评审、 测试大纲评审报告)
升级包(执行代码、部署文档、初始化 SQL、 □
38683 。
【 tar/jar. 】的含义:标识打包的名称。
2.1.2.2.非正式发布版
对于非正式发布 (如内部测试 )的产品 / 代码,一般使用附加日期、附加流水号或者 法记录,如 V1.1.4.20110112 。
Build 号的方
北京万度网络科技有限公司作业文件
万度
2.2. 版本号变更
2.2.1 版本号变更流程图
f) 产品开发经理: 经审批通过后,研发产品新版本,完成研发后提交测试经理测试。 g) 测试经理: 完成产品新版本测试后提交质量保证部经理审批发布产品新版本。 h) 质量保证部经理: 批准产品新版本发布。
2.2.2.4.产品新版本入库:
i) 配置管理员: 收到产品入库申请单及入库产品文档和部署包后提交研发中心总监审批 后将产品文档和部署包入产品库。
j) 研发中心总监: 批准产品新版本入库。
2.3. 入库流程
1) 项目立项后两天内, a) 开发经理向配置管理员申请版本号,由配置管理员根据“版本号定义”规范审核版本号是 否可用 ;
b) 开发经理提交《开发计划》 。《开发计划》内必须包括 入库时间(项目上线一周内) 、版本 号;
2) 配置管理员根据《开发计划》整理《产品入库跟踪表》
北京 WAND网U 络科技有限公司 XXXX年 XX 月 XX 日生效
北京万度网络科技有限公司作业文件
万度
修订历史记录
日期
版本
说明
作者
审批人
2009/09/01
A/0
第一版
XX
XX
2009/12/03
A/1
增加了修改记录; 调整了 XX
XX
部署包、 评审报告、 测试
报告的项目; 测试报告变
成必须项; 业务策划由需
单
试大纲评审报告) *
升级包(执行代码、部署文
档、初始化 SQL、初始化文 研发中心
件、 BMS 菜单列表、割接方
案) *
设计文档(概要设计、详细
研发中心
设计、数据库设计) *
操作手册 *
质量保证部
源代码 *
研发中心
测试报告(原型测试报告、 开发测试报告、压力测试报
质量保证部
告) *
万度 新版本号
配置管理员:
【应用名】的含义:标识应用的名称。一般指产品名称、项目名称、中间件等应用名称。如统
一认证平台( SSO)。
【版本号】的含义:标志部署包及代码的版本。同上文档版本的规则,如
1.0.0.0 。
【日期】的含义:标志部署包及代码的封板日期。如
20110222 。
【 SVN号】的含义:标识部署包及代码的版本,系统是自动递增的。如
。列:产品名称、版本号、入库时间、
开发经理、 项目 / 产品经理、 预计入库时间、 实际入库时间、 是否按时入库 ; 《产品入库跟踪表》
每月发送给总监一次;每季度需审核一次;
3) 当到达入库时间后,
a) 开发经理应该 主动 申请入库, 产品经理 填写《版本入库申请表》 ;
b) 配置管理员根据《产品入库跟踪表》及时跟踪
万度
附录 III
程序源码版本号列表:
序号
子系统名称
产品版本号
SVN版本号
SVN存放路径
作者
部署版本号列表:
序号
子系统名 称
版本号
部署总包 名称
二级子包 名称
部署包大小 ( K)
打包日期
VSS存放路径
作者
北京万度网络科技有限公司作业文件
万度
附录 IV
产品升级版本审批表
申请人 产品名称 原产品版本
申请原因
日期:
年月 日
□ □ □
□ □ □
□
□ □ □ □
北京万度网络科技有限公司作业文件
项目管理文档(会议纪要、 立项审批、项目周报) 参考资料 其他
项目部门
万度 □
□ □
备注: * 表示为必需文档 。 其中割接方案为项目入库时必需项;升级文件为产品升级时必需项;
项目变更记录表
日期
变更 类型
文档,文件名称
产品 升级 背景 描述
申请 时间
项目 编号
CN:X.X.X.X
升级产品版本
CN:X.X.X.X
□性能改良 □BUG修改 □客户需求
□功能完善
□创新
□其他
时间
完成内容
升级计划
备注
预计 成本
人/ 月
本次升级 内容
本次升级可 能存在风险
升级方案评 审意见
研发经理
产品经理 意见
研发总监 意见
研发 小组 成员 产品总监 意见 质检中心 总监意见
VSS,并刻盘两份。一份由部门中心保存,
2.4. 出库流程
1) 申请人填写《版本出库申请表》 ,分为两类:
a) 文档设计和源代码使用申请:由开发经理填写《版本出库申请表》 部门经理及部门总监签字;
,并提交给发起人所属
b) 部署包使用申请:由发起人 (项目经理 / 产品,维护人员 ),填写《版本出库申请表》 ,并提 交给发起人所属部门经理签字;
初始版本为 1.0.0.0 。 【主版本号】 :产品大功能 / 整体架构 / 用途产生变更时增加。 【从版本号】 :产品模块级功能有一定的增强。 【功能版本号】 :产品有一些小的变动,一般是缺陷修复或通用性修改。 【项目号】:应用在项目中个性化需求。
北京万度网络科技有限公司作业文件
万度
2.1.2. 代码 / 部署包版本
2) 配置管理员根据《版本出库申请表》 ,负责从 VSS下载申请的内容,并发给申请人。
2.5. 产品列表流程
产品入库更新时, 《产品列表》需要实时更新, 研发中心 的配置管理员,在更新的同时需发送对 方,以确保《产品列表》的统一性。
3. 适用范围
本制度适用于公司产品、项目、公用组件等公司财产。
4. 附录
2.1. 版本号定义