原材料代码制定原则及管理规范(2013-07-01)

原材料代码制定原则及管理规范(2013-07-01)
原材料代码制定原则及管理规范(2013-07-01)

原材料代码制定原则及管理规范

一、原材料代码编写标准;

1、凡我公司新进配件及原材料或我公司从供应商处定制的配件原材料,供应商没有提供材料代码的由设计技术中心按此编码原则进行编号,并填写“倍特厨柜编码登记表”并确认代码,由采购部,财务部,质检部签字后生效,再任实际工作中流转的唯一性。需作培训的,上报人力资源部,同时准备四件样品,并做好编码分别交采购部,质检部,技术部,供应商存档。

2、编码原则如下:

2-1配件类:

(a):大五金BF□□□□□

此处为01-20两位数序列号。

□内填写品牌首个字母大写,□内

填写A表示配螺钉填写N表示不配

螺钉。

以BF开头□内为配件名称的首个拼

音字母大写。

(b):小五金SF□□□□□

此处为01-20两位数序列号。

□内填写品牌首个字母大写,□内

填写A表示配螺钉填写N表示不配

螺钉。

以SF开头□内为配件名称的首个拼

音字母大写。

(c):电器类AF□□□□□

此处为01-20两位数序列号。

□内填写品牌首个字母大写,□内

填写A表示配螺钉填写N表示不配

螺钉。

以AF开头□内为配件名称的首个拼

音字母大写。

(例如:BFCBA02表示:百隆抽屉两副用于柜内; SFLBA02表示:柏丽雅拉手一副;AFWSN01表示:SIEMENS微波炉一件不配送螺钉。)

2-2材料类:

(a):板材类 B□□□□□

此处为01-20两位数序列号。

□□内填写材料厚度首个英文字母

大写

以B开头□内为材料名称的首个拼

音字母大写

[例如:BSE02表示:两块18mm厚度双饰板(T是Three<3>的缩写;F是Five<5>的缩写;N 是Nine<9>的缩写;F是Fifteen<15>的缩写;S是Sixteen<16>的缩写;E是Eighteen<18>的缩写;T是Twenty<20>的缩写;TF是Twenty-Five<25>的缩写;)]

(b):门板类 DB□□□□□□

此处为01-20两位数序列号。

□内填写生产厂家第一个拼音字母

大写;□□内填写材料厚度首个英

文字母大写。

以DB开头□内为材料名称的首个拼

音字母大写

2-3辅料类:M□□□□□

此处为01-20两位数序列号。

PE (produce-生产)表示生产上用,IT(install-

安装)表示安装上用。

以M开头□内为辅料名称的首个拼音字母大写。(例如:MBIT02表示:玻璃胶两瓶。)

二、新进材料代码更新及管理办法:

1、所有新进材料一经确认编写代码后任何部门任何个人不得随意更改,如有需求需填写“倍特橱柜材料需求(变更)表”经公司领导及各部门协商同意后,设计技术中心根据需求以通知的形式告知各部门关于新进材料代码变更、增减、取消等相关事宜并存档。

2、在材料变更过程中与原有产品结构相冲突,相关负责人应邀请公司领导及各部门相关负责人以正式或非正式会议的形式进行讨论提出整改方案,设计技术中心参照会议内容及整改方案对现有产品结构作出调整后以通知的形式告知各部门并存档,需要集中培训的请及时向人力资源部提出申请。

3、以半年为周期,设计技术中心会根据各部门意见和建议对新进材料代码进行核对、调整、修改、淘汰、增删,确定新代码后已通知的形式告知各部门。

设计技术中心

2014-9-1

源代码安全管理制度V

技术部源代码控制管理制度V1.0 一、总则 1、目的: 为保障公司源代码安全不至于泄露,保证源代码的完整,明确源代码控制管理流程,特制定此管理办法。 2、使用范围: 本办法适用于所有涉及接触源代码的各部门各岗位,所涉及部门都必须严格执行本管理办法。 3、责权: 源代码直接控制管理部门为技术部。本办法管理重点在于控制管理源代码的完整性,不被非授权获取,不被非授权复制和传播。本办法所指源代码不仅限于公司开发人员自行编写实现功能的程序代码,而且还包括相应的开发设计文档及用于支撑整个平台系统运行所必须具备的第三方软件、控件和其它支撑库等文件。 二、管理内容及要求(根据部门工作情况撰写) 1、源代码完整性保障 所有系统的源代码及相应的开发设计文档均必须及时加入到指定的源代码服务器中的指定SVN库中。

我们研发的平台系统运行所必须的第三方软件、控件和其它支撑库等文件也必须及时加入源代码服务器中指定的SVN库中。 功能开始编写或者调整代码之前,其相应的设计文档必须签入SVN库(由测试组文档管理员负责检查)。 系统编码或代码调整优化结束后,提交技术测试组功能测试之前,相应的源代码必须提交到SVN库。 测试组对功能进行测试时必须从源代码服务器上的SVN库中获取代码,包括必须的第三方软件、控件和其它支撑库等文件,然后进行测试。 所有提交到SVN上的代码必须保证编译通过,而且提交的时候不会影响主干其它程序的正常运行. 2、源代码的授权访问 源代码服务器对于共享的SVN库的访问建立操作系统级的,基于身份和口令的访问授权。(由SVN管理员进行管理和设置) 在SVN库中设置用户,为不同用户分配不同的、适合工作的最小访问权限。要求连接SVN库时必须校验SVN中用户身份及其口令。在SVN库中要求区别对待不同用户的可访问权、可创建权、可编辑权、可删除权、可销毁权。每个用户切实保证自己的用户身份和口令不泄露,用户要经常更换自己在SVN库中账号的口令。同时,工作任务变化或岗位调整后SVN管理员要实时回收用户的相关权限。要获取不属于自己范围内的文件,例如:代码、数据库,需求文档等,需经项目经理和技术部经理审批同意后由SVN管理员授权。

软件版本管理规范标准[详]

软件版本管理规 第一章目的 本规详细规定软件项目版本管理的对象、存储目录、分支、权限、维护等容,使软件项目版本管理流程化并规化,确保在系统开发和实施过程中项目的完整性和一致性。 1.第二章适用围 所有系统开发及实施项目的软件项目都应进行版本管理。项目中所有正式文档和代码都应纳入配置库(可使用工具建立配置库,本文所述使用的是SVN)进行版本管理。 2.第三章职责 配置库管理员:负责配置库的日常维护和管理;监督开发及测试部门及时提交版本管理对象(即配置项)。 此岗位可由开发或测试人员兼任。 3.第四章容 4.1. 版本管理对象 包括但不限于: 项目总体计划 可行性研究报告 开发计划 需求说明书 需求设计原型 设计说明书 系统开发变更申请单 系统管理手册 用户操作手册 培训计划 培训记录 源程序 支持系统运行的配置文件 存储过程脚本 测试计划 测试用例 测试脚本 测试报告 上线计划

上线申请 版本维护日志 4.2. 配置库的目录结构 每个项目在配置库中应拥有唯一的项目名称。配置库目录结构与项目部的目录结构建议按下列格式创建。 配置库目录结构规划: ┠tags(发布) ┃├v1.0.0_T1_2016909 ┃├v1.0.0.33899_T1_20161009 ┃├v1.0.0_R1_20161109 ┃├v1.1.0_T1_20170109 ┃└v1.1.0_R1_20170209 ┠trunk(主版本) ┃└projectA ┃├src ┃├MY_MOOC ┃├doc ┃├tool ┃├。。。 ┖branches(分支) ├SY_ABC ├TJ_ABC ├WH_MOOC 其中,项目部的目录结构: |–projectA |–src (保存该项目的源程序) |–doc (保存项目相关文档) |–000.项目管理(保存项目过程管理相关文档) |–010.项目计划(保存项目计划相关文档) |–020.项目需求(保存项目需求相关文档) |–030.系统设计(保存项目设计相关文档) |–030.系统测试(保存项目代码测试相关文档) |–040.系统实施(保存项目部署实施相关文档) |–050.系统运维(保存项目运维文档,包括培训、用户手册等) |–060.技术资料(保存项目技术文档,包括第三方技术资料等)

Git源代码管理规范样本

Git源代码管理规范 一、分支管理 使用git进行源代码管理, 一般将某个项目的所有分支分为以下几条主线: 1.Master 顾名思义, 既然名字叫Master, 那么该分支就是主分支的意思。master分支永远是production-ready的状态, 即稳定可产品化发布的状态。 2.Develop 这个分支就是我们平常开发的一个主要分支了, 不论是要做新的feature还是需要做bug fix, 都是从这个分支分出来做。在这个分支下主要负责记录开发状态下相对稳定的版本, 即完成了某个feature或者修复了某个bug后的开发稳定版本。 3.Feature branches 这是由许多分别负责不同feature开发的分支组成的一个分支系列。new feature主要就在这个分支系列下进行开发。当功能点开发测试完毕之后, 就会合并到develop分支去。

4.release branches 这个分支系列从develop分支出来, 也就是预发分支。在预发状态下, 我们往往会进行预发环境下的测试, 如果出现缺陷, 那么就在该release分支下进行修复, 修复完毕测试经过后, 即分别并入master分支后develop分支, 随后master分支做正常发布。 5.Hotfix branches 这个分支系列也就是我们常说的紧急线上修复, 当线上出现bug且特别紧急的时候, 就能够从master拉出分支到这里进行 修复, 修复完成后分别并入master和develop分支。 下面这张图将完整展示这一个流程

二、工作原理Git的工作方式:

也就是说, 每次提交版本变动的时候, git会保存一个快照(snapshot)。如果文件没有被更改, git也不会再次保存, 而是提供一个到原来文件的链接。这样一来, git更像是一个小型的文件系统。另外, git的所有操作都能够是本地的, 仅仅在将新版本的内容上传到服务器上时才需要连接网络。 Git目录( repository) 是Git保存元数据和对象数据库的地方。这也是Git最重要的部分。

软件项目代码编码规范

变更履历

目录 1总则 (4) 2源代码完整性保障 (4) 3源代码的授权访问 (4) 4代码版本管理 (5) 4.1系统初验 (6) 4.2试运行 (6) 4.3系统终验 (7) 4.4系统验收标准 (7)

1总则 1、为保障公司源代码和开发文档安全不至于泄露,保证源代码的完整,明确源代码控制管理流程,特制定此管理办法。 2、本办法适用于所有涉及接触源代码的各部门各岗位。所涉及部门都必须严格执行本管理办法。 3、源代码直接控制管理部门为技术开发部。 4、本办法管理重点在于控制管理源代码的完整性,不被非授权获取,不被非授权复制和传播。 5、本办法所指源代码不仅限于公司开发人员自行编写实现功能的程序代码,而且还包括相应的开发设计文档及用于支撑整个系统运行所必须具备的第三方软件、控件和其它支撑库等文件。 2源代码完整性保障 1、所有软件的源代码文件及相应的开发设计文档均必须及时加入到指定的源代码服务器中的指定库中。 2、我们研发的产品软件运行所必须的第三方软件、控件和其它支撑库等文件也必须及时加入源代码服务器中指定的库中。 3、软件开始编写或者调整代码之前,其相应的设计文档和代码必须先从相应的SVN库进行SVNUpdate操作。软件编码或功能调整结束测试正确无误后,相应的源代码必须进行SVNCommit操作,在最终进行SVNCommit操作之前需要再进行SVNUpdate操作,查看是否有冲突产生,如果有冲突产生需要和冲突相关人一并解决冲突。 3源代码的授权访问 1、源代码服务器对于共享的SVN库的访问建立操作系统级的,基于身份和口令的访问授权。 第十条在SVN库中设置用户,并为不同用户分配不同的,适合工作的最小

源代码管理规范

1源代码管理 (1) 总则 (1) 源代码完整性保障 (1) 源代码的授权访问 (2) 代码版本管理 (2) 源代码复制和传播 (5) 系统测试验收流程 (5) 系统初验 (6) 试运行 (6) 系统终验 (6) 应用系统验收标准 (8) 文档评审通过标准 (9) 确认测试通过标准 (9) 系统试运行通过标准 (10)

1代码管理 总则 1、为保障公司源代码和开发文档安全不至于泄露,保证源代码的完整,明确源代码控制管理流程,特制定此管理办法。 2、本办法适用于所有涉及接触源代码的各部门各岗位。所涉及部门都必须严格执行本管理办法。 3、源代码直接控制管理部门为技术开发部。 4、本办法管理重点在于控制管理源代码的完整性,不被非授权获取,不被非授权复制和传播。 5、本办法所指源代码不仅限于公司开发人员自行编写实现功能的程序代码,而且还包括相应的开发设计文档及用于支撑整个系统运行所必须具备的第三方软件、控件和其它支撑库等文件。 源代码完整性保障 1、所有软件的源代码文件及相应的开发设计文档均必须及时加入到指定的源代码服务器中的指定库中。 2、我们研发的产品软件运行所必须的第三方软件、控件和其它支撑库等文件也必须及时加入源代码服务器中指定的库中。 3、软件开始编写或者调整代码之前,其相应的设计文档和代码必须先从相应的SVN库进行SVNUpdate操作。软件编码或功能调整结束测试正确无误后,相应的源代码必须进行SVNCommit操作,在最终进行SVNCommit操作之前需要再进行SVNUpdate操作,查看是否有冲突产生,如果有冲突产生需要和冲突相关人一并解决冲突。

源代码管理规范

代码管理制度 1总则 (2) 2源代码完整性保障 (2) 3源代码的授权访问 (2) 4代码版本管理 (3) 5源代码复制和传播 (4) 6系统测试验收流程 (5) 6.1 系统初验 (5) 6.2 试运行 (5) 6.3 系统终验 (5) 6.4 系统验收标准 (6) 6.5 文档评审通过标准 (7) 6.6 确认测试通过标准 (7) 6.7 系统试运行通过标准 (7)

1总则 1、为保障公司源代码和开发文档安全不至于泄露,保证源代码的完整,明确源代码控制管理流程,特制定此管理办法。 2、本办法适用于所有涉及接触源代码的各部门各岗位。所涉及部门都必须严格执行本管理办法。 3、源代码直接控制管理部门为技术开发部。 4、本办法管理重点在于控制管理源代码的完整性,不被非授权获取,不被非授权复制和传播。 5、本办法所指源代码不仅限于公司开发人员自行编写实现功能的程序代码,而且还包括相应的开发设计文档及用于支撑整个系统运行所必须具备的第三方软件、控件和其它支撑库等文件。 2源代码完整性保障 1、所有软件的源代码文件及相应的开发设计文档均必须及时加入到指定的源代码服务器中的指定库中。 2、我们研发的产品软件运行所必须的第三方软件、控件和其它支撑库等文件也必须及时加入源代码服务器中指定的库中。 3、软件开始编写或者调整代码之前,其相应的设计文档和代码必须先从相应的SVN库进行SVNUpdate操作。软件编码或功能调整结束测试正确无误后,相应的源代码必须进行SVNCommit操作,在最终进行SVNCommit操作之前需要再进行SVNUpdate操作,查看是否有冲突产生,如果有冲突产生需要和冲突相关人一并解决冲突。 3源代码的授权访问 1、源代码服务器对于共享的SVN库的访问建立操作系统级的,基于身份和口令的访问授权。 第十条在SVN库中设置用户,并为不同用户分配不同的,适合工作的最小访问权限。要求连接SVN库时必须校验SVN中用户身份及其口令。在SVN库中要求区别对待不同用户的可访问权、可读权、可写权。

项目软件版本号管理规范

项目软件版本号管理规范

历史修改记录 一. 目的

1.1软件版本按照一定的规则保存所有版本,避免发生版本丢失或混淆等现象, 并且可以快速准确的查找到任何版本。 1.2软件版本规范有利于公司各部门之间的对接工作,有利于公司内部资料统一 管理。 1.3本文档是为规范研发部软件版本管理而制定的。 二. 范围 2.1本文档为研发部软件开发版本提供有关版本管理规范的相关内容,包括:2.2版本标识方法及管理 2.3版本升级 2.4文档及源码的备份制度 2.5所有研发部软件工程师成员都必须遵照项目软件管理规范操作,公司内部使 用按照文档及源码存放备份制度。 三. 版本管理 3.1版本号规则 3.1.1每个归档版本都有两个版本号:内部版本号和外部版本号。版本号使用 VP规则,V(Version)是指外部版本号(研发测试版本),P(Patch)是指补丁版本号(可选)。 3.1.2版本号命名:V/B+主版本号+次版本号+修订版本号+日期版本号

3.2版本号修改规则 3.2.1主版本号:当功能模块有较大的变动,比如增加模块或是整体架构发生 变化。此版本号由项目决定是否修改。 3.2.2次版本号:相对于主版本号而言,次版本号的升级对应的只是局部的变 动,但该局部的变动造成程序和以前版本不能兼容,或者对该程序以前的协作关系产生了破坏,或者是功能上有大的改进或增强。此版本号由项目决定是否修改。 3.2.3修订版本号:一般是Bug 的修复或是一些小的变动或是一些功能的扩 充,要经常发布修订版,修复一个严重Bug 即可发布一个修订版。此版本号由项目经理决定是否修改。 3.2.4日期版本号:用于记录修改项目的当前日期,每天对项目的修改都需要 更改日期版本号。此版本号由开发人员决定是否修改。 如: V8.1.0.XXX (上一级版本号有变动时,下级要归零) 3.3版本号修改举例说明 如此时版本号为:V8.1.0.XXX ,此时为内部测试阶段 3.3.1 开发人员修复了测试人员提交的bug并经测试人员测试验证关闭bug 之后,发布到外网时,此时就进入了软件的下一个阶段,版本号可改为: V8.1.1.XXXX ,如当前日期跟上一个版本号的日期不一样,版本号可改为: V8.1.1.XXX。

代码版本管理规范_v1.1

XXXXXXXX 代码版本管理规范

历史版本

目录 历史版本 (2) 1引言 (4) 1.1目的 (4) 1.2管理工具 (4) 2现状概述 (5) 3现状分析 (5) 3.1现状详述 (5) 3.2目标细化 (6) 3.3SVN版本管理 (6) 3.3.1概述 (6) 3.3.2使用对比 (7) 4完整的实施方案 (9) 4.1开发阶段 (9) 4.2预发布测试阶段 (9)

1引言 1.1目的 为了规范和制度化公司的软件版本管理制度,并保障项目开发资料的完整性和安全性,同时明确开发源代码的控制管理流程,特此制定此规范。 1.2管理工具 沿用SVN管理工具来进行开发的版本管理,源代码管理和开发资料归档。

2现状概述 目前公司研发部门对于代码的版本管理方式较为简单,只是在每次发版后做了基线库存档,导致所有正在开发的需求和项目都在同一个目录里面进行修改,造成每次发版的代码都有可能包含了本次发版以外的内容。 这样会造成如下两点影响: ●会有不稳定的因素存在,比如:测试只会对当前需要发版的内容进行测试,但是代码库 中同时存在多个版本和项目的代码,对于本次发版无涉及的代码没有进过测试就部署到了服务器上,影响运行的稳定性。 ●一旦出现点问题不好定位,比如:出现问题后通常会优先排查发版涉及的内容,但是部 分问题是由于其他项目代码引起的。 因此,随着公司和项目规模的壮大,对软件代码版本管理提出了更高的要求。 3现状分析 3.1现状详述 当前代码版本管理现状如下: 1.所有的开发都在一个目录里面做,各种需求、项目、代码、文件混杂在一起。 2.提交测试服务器时,只考虑了编译能通过,而没有考虑功能本身有没有完成。 3.测试出bug以后,会在开发目录进行修改,然后再次提交到测试服务器。这时提交的 代码就可能包含了他人对其他功能/项目的修改,而测试又只会针对此bug再做测试。 这就导致了除了此bug之外的修改可能会没有测试过就直接发布到了服务器上,引起预发布环境不稳定并增加预发布bug数量。 总体来说,当前工作流程是:预发布出bug,研发修改,再提交测试,然后预发布测试

源代码管理制度

源代码管理制度 1代码管理 1.1总则 1、为保障公司源代码和开发文档安全不至于泄露,保证源代码的完整,明确源代码控制管理流程,特制定此管理办法。 2、本办法适用于所有涉及接触源代码的各部门各岗位。所涉及部门都必须严格执行本管理办法。 3、源代码直接控制管理部门为技术开发部。 4、本办法管理重点在于控制管理源代码的完整性,不被非授权获取,不被非授权复制和传播。 5、本办法所指源代码不仅限于公司开发人员自行编写实现功能的程序代码,而且还包括相应的开发设计文档及用于支撑整个系统运行所必须具备的第三方软件、控件和其它支撑库等文件。 1.2源代码完整性保障 1、所有软件的源代码文件及相应的开发设计文档均必须及时加入到指定的源代码服务器中的指定库中。 2、我们研发的产品软件运行所必须的第三方软件、控件和其它支撑库等文件也必须及时加入源代码服务器中指定的库中。 3、软件开始编写或者调整代码之前,其相应的设计文档和代码必须先从相应的SVN库进行SVNUpdate操作。软件编码或功能调整结束测试正确无误后,相应的源代码必须进行SVNCommit操作,在最终进行SVNCommit操作之前需要再进行SVNUpdate操作,查看是否有冲突产生,如果有冲突产生需要和冲突相关人一并解决冲突。 1.3源代码的授权访问 1、源代码服务器对于共享的SVN库的访问建立操作系统级的,基于身份和口令的访问授权。在SVN库中设置用户,并为不同用户分配不同的权限,适合工作的最小访问权限。

要求连接SVN库时必须校验SVN中用户身份及其口令。在SVN库中要求区别对待不同用户的可访问权、可读权、可写权。 2、曾经涉及、触及源代码的计算机在转作它用,或者离开研发部门之前必须由网络管理人员全面清除计算机硬盘中存储的源代码。如果不能确定,必须对计算机中所有硬盘进行全面格式化后方可以转做它用或离开研发部门。 1.4代码版本管理 1、终端软件的版本标识管理 终端软件版本由终端型号、版本号和内部修订号来进行标识。终端型号:终端型号是硬件标识号,也唯一的标识了我们的项目。版本号:由“<主版本号>.<次版本号>.<修订号>”三段组成,中间是点号分开。版本号的目的主要是管理终端软件的对外发布,终端软件的bug的记录和统计,主要是针对于版本号的,测试部、项目部、客户等会记录某个版本号的终端软件存在哪些bug,bug会在哪个版本号中得到修正。终端软件一个新的版本号出来后,我们会统计新的版本号解决了上一个版本号中的哪些bug,以及增加了哪些新功能,等等。 内部修订号:也就是“应用程序的源代码的svn修订号”,主要是由软件部和测试部内部来使用,内部修订号唯一标识我们的终端软件,即:通过内部修订号能够唯一的找出我们发布的终端软件所对应的全部软件源代码,目的是为了软件排错使用。 另外,终端软件在发布时,还会给出发布日期,以便开发、测试、项目、客户等相关人员参考。 2、终端软件版本发布管理 终端软件主要是以版本号为基准,对外发布,目前采用不定时发布策略,发布的时间由软件部、项目部和客户方根据情况,共同商量决定。 由于目前项目时间紧,终端软件无法得到完整的测试就要发布,在发布之后,有一些需要紧急需要修复的bug,软件部需要紧急修复后就要发布更新包,以便用户能够使用,所以,在一个版本号发布后,需要进行多次修订,对于这些修订的版本,其版本号保持不变,内部修订发生变化。 3、软件bug记录、管理和统计 软件bug的记录、管理和统计主要以版本号为基准,但为了软件开发人员能够找到bug

软件版本管理规范19726

软件版本管理规范 第一章目的 本规范详细规定软件项目版本管理的对象、存储目录、分支、权限、维护等内容,使软件项目版本管理流程化并规范化,确保在系统开发和实施过程中项目的完整性和一致性。 1.第二章适用范围 所有系统开发及实施项目的软件项目都应进行版本管理。项目中所有正式文档和代码都应纳入配置库(可使用工具建立配置库,本文所述使用的是SVN)进行版本管理。 2.第三章职责 配置库管理员:负责配置库的日常维护和管理;监督开发及测试部门及时提交版本管理对象(即配置项)。 此岗位可由开发或测试人员兼任。 3.第四章内容 4.1. 版本管理对象 包括但不限于: 项目总体计划 可行性研究报告 开发计划 需求说明书

需求设计原型 设计说明书 系统开发变更申请单 系统管理手册 用户操作手册 培训计划 培训记录 源程序 支持系统运行的配置文件 存储过程脚本 测试计划 测试用例 测试脚本 测试报告 上线计划 上线申请 版本维护日志 4.2. 配置库的目录结构 每个项目在配置库中应拥有唯一的项目名称。配置库目录结构与项目内部的目录结构建议按下列格式创建。

配置库目录结构规划: ┠tags(发布) ┃├v1.0.0_T1_2016909 ┃├v1.0.0.33899_T1_20161009 ┃├v1.0.0_R1_20161109 ┃├v1.1.0_T1_20170109 ┃└v1.1.0_R1_20170209 ┠trunk(主版本) ┃└projectA ┃├src ┃├MY_MOOC ┃├doc ┃├tool ┃├。。。 ┖branches(分支) ├SY_ABC ├TJ_ABC ├WH_MOOC 其中,项目内部的目录结构: |–projectA

源代码管理规范

1源代码管理 (1) 1.1总则 (1) 1.2源代码完整性保障 (1) 1.3源代码的授权访问 (2) 1.4代码版本管理 (2) 1.5源代码复制和传播 (5) 1.6系统测试验收流程 (5) 1.6.1系统初验 (6) 1.6.2试运行 (6) 1.6.3系统终验 (6) 1.6.4应用系统验收标准 (8) 1.6.5文档评审通过标准 (9) 1.6.6确认测试通过标准 (9) 1.6.7系统试运行通过标准 (10)

1代码管理 1.1总则 1、为保障公司源代码和开发文档安全不至于泄露,保证源代码的完整,明确源代码控制管理流程,特制定此管理办法。 2、本办法适用于所有涉及接触源代码的各部门各岗位。所涉及部门都必须严格执行本管理办法。 3、源代码直接控制管理部门为技术开发部。 4、本办法管理重点在于控制管理源代码的完整性,不被非授权获取,不被非授权复制和传播。 5、本办法所指源代码不仅限于公司开发人员自行编写实现功能的程序代码,而且还包括相应的开发设计文档及用于支撑整个系统运行所必须具备的第三方软件、控件和其它支撑库等文件。 1.2源代码完整性保障 1、所有软件的源代码文件及相应的开发设计文档均必须及时加入到指定的源代码服务器中的指定库中。 2、我们研发的产品软件运行所必须的第三方软件、控件和其它支撑库等文件也必须及时加入源代码服务器中指定的库中。 3、软件开始编写或者调整代码之前,其相应的设计文档和代码必须先从相应的SVN库进行SVNUpdate操作。软件编码或功能调整结束测试正确无误后,相应的源代码必须进行SVNCommit操作,在最终进行SVNCommit操作之前需要再进行SVNUpdate操作,查看是否有冲突产生,如果有冲突产生需要和冲突相关人一并解决冲突。

软件版本管理规范标准

软件版本管理规 V1.0.0 文档版本变更记录:

目录 前言 (3) 1 围 (4) 2 术语和定义 (4) 2.1 软件 (4) 2.2 产品软件 (4) 2.3 演示软件 (4) 3 软件版本命名规则 (4) 3.1 软件版本命名组成 (4) 3.2 产品软件版本命名 (4) 3.3 演示软件版本命名 (5) 3.4 正式版本号的升级规则 (6) 3.4.1 软件版本升级规则 (6) 3.4.2 演示版本升级规则 (6) 3.5 版本的安装文件命名规则及存放路径 (6) 4 软件版本发布流程 (7) 5 管理条例 (7) 6 附录 (7)

前言 为规部门产品软件版本的管理与控制,保证产品版本的有效与质量,制定本标准。本标准由移动金融事业部拟制。 本标准于2015年6月首次发布。

软件版本管理规定 1围 本标准规定了移动银行事业部产品软件版本的控制与管理。 本标准适用于移动银行事业部产品软件版本的控制与管理。 2术语和定义 下列定义适用于本标准。 2.1软件 指与产品相关的所有软件,可以分为产品软件和演示软件。 2.2产品软件 已签订合同,有明确交付日期的产品。 2.3演示软件 处于研发阶段,并未正式投入生产的应用。 3软件版本命名规则 3.1软件版本命名组成 产品的正式软件版本命名由四部分组成。第一部分为主版本号,第二部分为次版本号,第三部分为修订版本号,第四部分为日期版本号。 产品的演示版本命名由四部分组成。第一部分为主版本号,第二部分为次版本号,第三部分为修订版本号,第四部分为日期版本号。 3.2产品软件版本命名 产品软件版本的命名规则如下所示:

项目版本管理规范

项目版本管理规范 版本控制 1.1.目的 按照一定的规则保存配置项的所有版本,避免发生版本丢失或混淆等现象,并且可以快速准确的查找到配置项的任何版本。 1.2.角色与职责 所有项目成员都必须遵照版本控制规程操作配置库 1.3.配置项状态变迁规则 配置项的状态有3种:“草稿”(Draft)、“正式发布”(Released)和“正在修改”(Changing)。配置项状态变迁如图所示: 配置项刚建立时其状态为“草稿”。配置项通过评审(或审批)后,其状态变为“正式发布”。此后若更改配置项,必须依照“变更控制规程”执行,其状态变为“正在修改”。当配置项修改完毕并重新通过评审(或审批)时,其状态又变为“正式发布”,如此循环。 1.4.配置项版本号规则 配置项的版本号与配置项的状态紧密相关。 ?处于“草稿”状态的配置项的版本号格式为:0.YZ。YZ数字范围为01-99。随着草稿的 不断完善,“YZ”的取值应该递增。“YZ”的初值和增幅由项目组成员自己把握。 ?处于“正式发布”状态的配置项的版本号格式为:X.Y。X为主版本号,取值范围为1-9。 Y为次版本号,取值范围为0-9。配置项第一次“正式发布”时,版本号为1.0。如果配置项的版本升级幅度比较小,一般只增大Y值,X值保持不变。只有当配置项版本升级幅度比较大时,才允许增大X值。

处于“正在修改”状态的配置项版本号格式为:X.YZ。配置项正在修改时,一般只增大Z值,X.Y值保持不变。当配置项修改完毕,状态重新成为“正式发布”时,将Z值设置为0,增加X.Y值。 1.5.版本控制的主要步骤 1.5.1.创建配置项 项目成员依据《配置管理计划》,在配置库的开发库中创建属于其任务范围内的配置项。此时配置项的状态为“草稿”,其版本号格式为0.YZ。 1.5. 2.修改处于“草稿”状态的配置项 项目成员使用配置管理软件的Checkout/Checkin功能,可以自由修改处于“草稿”状态的配置项(不受变更控制规程约束),版本号格式为0.YZ。 1.5.3.评审和CCB审批 配置项定稿后要接受评审和CCB审批。 1.5.4.配置项入基线库 配置项通过评审和CCB批准后,由配置管理员纳入基线库,则配置项的状态从“草稿”变迁为“正式发布”,版本号格式为X.Y。 1.5.5.版本发布 基线库里有新的配置项产生,或者基线库里的配置项版本升级时,配置管理人员要做版本发布,通过会议或EMAIL等方式通知项目组内其它人。通知中需要指明配置项在配置管理库中的目录名、文件名、版本号。

产品版本管理规范

基于Tortoise SVN的软件产品版本管理规范[草稿]

目录 1. 引言 (1) 1.1. 目的 (1) 1.2. 范围 (1) 1.3. 术语定义 (1) 1.4. 参考资料 (2) 1.5. 版本控制记录 (2) 1.6. 版本更新记录 (2) 2. 版本管理 (4) 2.1. 版本标示方法 (4) 2.1.1. 正式版本 (4) 2.2. 目录结构 (5) 2.3. 文档的存放 (6) 2.3.1. 开发文档的存放 (6) 2.3.2. 源代码的存放 (6) 2.3.3. SQL的语句存放 (7) 2.3.4. 发行文档的存放 (7) 2.4. 配置管理流程 (7) 2.5. 权限控制的管理 (8) 3. 更新管理 (9) 3.1. 源程序的修改 (9) 3.2. 版本升级 (10) 3.2.1. 版本升级原则 (10) 3.2.2. 新版本发布 (11) 3.3. 文档的变更 (11) 4. 备份管理 (12) 5. 版本工具Tortoise SVN的使用 (13)

1.引言 版本控制就是对软件开发过程中所创建的配置对象不同版本进行管理,保证任何时间都可以取到正确的版本以及版本的组合。 版本控制的主要功能是记录开发过程中的每一次修改,让开发的工作可以随时检查过往历史记录和获得正确版本,是系统的成长记录。 1.1. 目的 本文档的编制是为了规范产品部、研发部、测试部对软件产品版本的管理。 1.2. 范围 本文档为产品部、研发部、测试部的管理员提供有关版本管理规范的相关内容,包括: ●版本标识方法 ●软件系统数据的存放 ●文档的修改控制 ●文档的备份制度 1.3. 术语定义 SCM 软件配置管理(Software Configuration Management)缩写 SVM 软件版本管理(Software Version Management)缩写 SVN 一个开源的版本控制系统Subversion. 文档 一种数据媒体和其上所记录的数据。

源代码管理规范

源代码管理规范 标准化文件发布号:(9312-EUATWW-MWUB-WUNN-INNUL-DQQTY-

代码管理制度 1总则.................................................................................................. 错误!未定义书签。2源代码完整性保障............................................................................ 错误!未定义书签。3源代码的授权访问............................................................................ 错误!未定义书签。4代码版本管理 ................................................................................... 错误!未定义书签。5源代码复制和传播............................................................................ 错误!未定义书签。6系统测试验收流程............................................................................ 错误!未定义书签。 系统初验........................................................................................... 错误!未定义书签。 试运行............................................................................................... 错误!未定义书签。 系统终验........................................................................................... 错误!未定义书签。 系统验收标准................................................................................... 错误!未定义书签。 文档评审通过标准........................................................................... 错误!未定义书签。 确认测试通过标准........................................................................... 错误!未定义书签。 系统试运行通过标准....................................................................... 错误!未定义书签。

源代码及文档管理规范

源代码管理文档管理规范 第一章总则 第一条为保障公司源代码和开发文档安全,保证源代码的完整,明确源代码控制管理流程,特制定本源代码管理办法。 第二条本办法适用于所有涉及接触源代码的各部门各岗位。所涉及部门都必须严格执行本管理办法。 第三条源代码直接控制管理部门为产品管理。原代码的内容为我单位万网工程建站的所有相关网站,模板,四川机构网网站代码以及数据库等。 第四条本办法管理重点在于控制管理源代码的完整性,不被非授权获取,不被非授权复制和传播。 第五条本办法所指源代码不仅限于公司开发人员自行编写实现功能的程序代码,而且还包括相应的开发设计文档及用于支撑整个系统运行所必须具备的第三方软件、控件和其它支撑库等文件。 第二章源代码完整性保障 第六条所有软件的源代码文件及相应的开发设计文档均必须及时加入到指定的源代码服务器中的指定库中。 第三章源代码的授权访问 第七条源代码服务器对于共享的TFS库的访问建立操作系统级的,基于身份和口令的访问授权。 第八条在TFS库中设置用户,并为不同用户分配不同的,适合工作的最小访问权限。要求连接TFS库时必须校验TFS中用户身份及其口令。在TFS库中要求区别对待不同用户的可访问权、可读权、可写权。 第九条曾经涉及、触及源代码的计算机在转作它用,或者离开研发部门之前必须由网络管理人员全面清除计算机硬盘中存储的源代码。如果不能确定,必须对计算机中所有硬盘进行全面格式化后方可以转做它用或离开研发部门。 第四章源代码复制和传播 第十条源代码向研发部门以外复制必须获得总经理的书面授权。并必需记录

复制人、批准人、复制时间、复制目的、文件流向、文件版本或内容。 第十一条源代码以任何介质形式进行存储的备份,必须由专人负责保管。对于这些介质地借阅,用于研发部内部使用的必须获得研发部经理的授权,对于用于研发部以外使用的必须获得总经理的书面授权。 第十二条源代码的借阅、复制必须进行详细的登记,必需记录借阅人、批准人、借阅时间、借阅目的、文件流向、文件版本或内容、归还时间。 第十三条任何纸质材料的借阅都必需记录借阅人、批准人、借阅时间、借阅目的、文件流向、文件版本或内容、归还时间。 第十四条对于因合作需要,需要向外复制、传播、分发源代码的,不论是全部还是部分代码和资料,均必需和对方签订技术、源码的保密协定,明确对方应当承担的对源码保密的责任和义务。 第十五条所有已有的开发文档与当前的代码进行统一管理。 第十六条新开发的项目和系统验收时必须与同相关的开发文档同时进行验收。 第五章开发文档管理规范 第十七条所有已有的开发文档与当前的代码进行统一管理 第十八条本规范执行日之后的所有项目的开发必须按开发的基本规则输出开发文档进行备案。 第十九条开发周期在1-3个月以内的项目开发文档保密时效为6个月,开发周期在3个月以上的为一年,保密时效计时为项目结束成功验收之后开始。 第二十条在项目开发中任何以不得未经授权向外发布、流传开发相当的任何文档。

软件源码版本管理系统要求规范

软件版本管理规范 1.第一章目的 本规范详细规定软件项目版本管理的对象、存储目录、分支、权限、维护等内容,使软件项目版本管理流程化并规范化,确保在系统开发和实施过程中项目的完整性和一致性。 2.第二章适用范围 所有系统开发及实施项目的软件项目都应进行版本管理。项目中所有正式文档和代码都应纳入配置库(可使用工具建立配置库,本文所述使用的是SVN)进行版本管理。 3.第三章职责 配置库管理员:负责配置库的日常维护和管理;监督开发及测试部门及时提交版本管理对象(即配置项)。 此岗位可由开发或测试人员兼任。 4.第四章内容 4.1. 版本管理对象 包括但不限于: ?项目总体计划 ?可行性研究报告 ?开发计划 ?需求说明书 ?需求设计原型 ?设计说明书 ?系统开发变更申请单 ?系统管理手册 ?用户操作手册 ?培训计划 ?培训记录 ?源程序 ?支持系统运行的配置文件

?存储过程脚本 ?测试计划 ?测试用例 ?测试脚本 ?测试报告 ?上线计划 ?上线申请 ?版本维护日志 4.2. 配置库的目录结构 每个项目在配置库中应拥有唯一的项目名称。配置库目录结构与项目内部的目录结构建议按下列格式创建。 配置库目录结构规划: ┠tags(发布) ┃ ├v1.0.0_T1_2016909 ┃ ├v1.0.0.33899_T1_20161009 ┃ ├v1.0.0_R1_20161109 ┃ ├v1.1.0_T1_20170109 ┃ └v1.1.0_R1_20170209 ┠trunk(主版本) ┃ └projectA ┃ ├src ┃ ├MY_MOOC ┃ ├doc ┃ ├tool ┃ ├。。。 ┖branches(分支) ├SY_ABC ├TJ_ABC ├WH_MOOC

版本管理规范

版本管理规范 一、版本管理办法 1.1目的 按照一定的规则保存项目源程序的所有版本,避免发生版本丢失或混淆等现象,并且可以快速准确的查找到项目各个板块的任何版本。为保障公司源代码和开发文档安全不被泄漏,保证选代码的完整性,明确源代码控制管理流程,特制定此管理办法。 1.2适用部门 本办法适用于所有涉及接触源代码的各部门各岗位。所涉及部门都必须严格执行本管理办法。 1.3管理部门 源代码直接控制管理部门为软件部。 1.4控制范围 本办法所指源代码不仅限于公司开发人员自行编写实现功能的程序代码,而且还包括相应的开发设计文档及用于支撑整个系统运行所必须具备的第三方软件、控件和其它支撑库等文件。 1.5角色与职责 所有项目成员都必须遵照版本控制规则操作各个项目板块。 1.6版本管理工具Virsual SVN 用此工具对项目开始阶段的开发,和项目中期的变更进行版本的管理。避免发生版本丢失或混淆等现象,详细使用方法见:《Virsual SVN操作细则》 1.7项目各板块版本变迁规则 各板块的状态有3种:“草稿”(Dralt)、“正式发布”(Released)和“正在修改”(Changing) 各板块状态变迁如图所示: 各板块刚建立时其状态为“草稿”。各板块通过评审(试用)后,其状态变为“正式发布”。此后若更改各板块源代码,必须填写“版本变更情况表”及“版本变更状态跟踪表”,且版本状态变为“正在修改”,修改后通过审批(试用)其状态又为“正式发布”。以此循环。 二、SVN管理规范 2.1帐号密码的配发规则 根据岗位需要,针对不同人员,设置不同权限。遇岗位变更,随时增加删除权限。用户名:为姓名的‘姓’的全拼音+‘名’的开头拼音。 密码:一人一密码。 2.2上传文件注意事项 1.修改后的文件及文件夹的名字,跟修改前的必须同名,否则识别不了,当成新增

软件公司-源代码管理制度资料

软件公司-源代码管理 制度

源代码管理制度(讨论稿) 一、总则 为了加强公司产品、项目开发源代码及相关技术文档的管理,进而确保项目实施的效率和质量,特制定本办法。 二、适用范围 产品、项目开发技术人员及项目实施负责人。 三、定义 项目:是指通过公司立项确定需要按期实施的项目。 项目实施:是指为完成立项项目进行的阶段性或特定领域的实施过程,主要包括研发实施和部署实施。 源代码:是指产品、项目研发过程中所产生的程序源代码。 技术文档:是指产品、项目配套的各类设计文档、操作手册等技术性文档。 版本管理服务器:指公司架设供所有开发人员使用的Subversion(SVN)服务器。 源代码提交:指开发人员通过客户端程序将所编写源代码上传至版本管理服务器的操作过程。 四、源代码日常管理流程 源代码管理是技术研发过程的日常管理,主要包括源代码提交、源代码审阅、异常协调等几个环节。

否 五、源代码结构设定 源代码结构是指源代码在版本管理服务器上存放的文件夹结构。源代码结构的设定由项目实施负责人决定。 源代码结构设定有几项基本要求: ?必须设置文档文件夹:每一个独立项目或子项目源代码文件内,至少设定一个docs或doc文件夹以存放仅与该项目相关技术文档和参考资料; ?必须考虑支持库:源代码结构中,应考虑具体项目所引用的非标 第三方支持库或框架的存放位置;

?必须可以直接编译:源代码结构必须是可直接编译结构。即任何一台新装计算机,在安装了必要的开发环境软件以后,通过从版本管理服务器上签出整套源代码后,应该可以直接完成编译。六、500提交 500提交是指项目实施期间,所有参与开发的技术人员,每日5:00必须将当日所编制的源码或技术文档提交至版本管理服务器。源代码及技术文档提交有如下几项要求: ?任何一次提交都必须对所提交内容进行注释; ?提交注释必须包含的信息项包括:所属模块或功能(必须与项目实施进度计划一致)、性质(正常开发、修改BUG、扩展功 能)、状态(编码中(x%)、调试通过、独测通过、联测通 过)、更新说明(本次提交所涉及修改部分的简要说明)。 ?提交注释必须以下图示例格式为准。 ?所提交源码必须是编译无错版本。 七、530审阅 530审阅是指项目实施负责人,每日下班前审阅版本服务器上所有下属技术人员所提交的源代码和技术文档。 源代码审阅有以下几点审阅标准:

项目软件版本管理方式

项目软件管理规范版本号:A 编制日期 审核日期 批准日期

历史修改记录 版本号修订内容修订时间修订人

一. 目的 1.1软件版本按照一定的规则保存所有版本,避免发生版本丢失或混淆等现象, 并且可以快速准确的查找到任何版本。 1.2软件版本规范有利于公司各部门之间的对接工作,有利于公司内部资料统一 管理。 1.3本文档是为规范安徽瑞德医疗器械制造有限公司研发部软件版本管理而制 定的。 二. 范围 2.1本文档为研发部软件开发版本提供有关版本管理规范的相关内容,包括:2.2版本标识方法及管理 2.3版本升级 2.4文档及源码的备份制度 2.5所有研发部软件工程师成员都必须遵照项目软件管理规范操作,公司内部使 用按照文档及源码存放备份制度。 三. 版本管理 3.1版本号规则 3.1.1每一个归档版本都有两个版本号:内部版本号和外部版本号。版本号使 用VBP规则,V是指外部版本号(研发测试版本),B是指内部版本号(受控版本),P是指补丁版本号(可选)。 3.1.2版本号命名:项目名称+发布版本(对内/对外)+版本更新记录 3.2版本控制记录

3.2.1版本状态变迁要遵守一定的规则,内部先生成一个内部版本,提交测试 审批,通过了则由开发人员进行版本归档受控,生成外部版本。(测试人员在测试过程中根据《软件测试规程》检测生成《软件测试报告》再由项目组内部讨论是否能生成新的版本)不通过则为无效版本,需要软件开发人员再进行修改,直至通过。通过后生成表格记录,再和源码一起打包受控形成外部版本。 3.2.2版本审核记录表如下:每次审核记录添加,审核通过后作为开发文档一 起打包受控。 内部版本状 态外部版本状 态 开发人审核人批准人发布时间 B1.0 V1.0 研发部软件 工程师 3.3版本更新记录 3.3.1版本更新软件工程师根据项目内容的变更,优化软件功能的,需要变更 内部版本号提交测试审批,通过了则由开发人员进行版本归档,(测试人员在测试过程中根据项目软件变更优化的内容,结合项目软件整体结合进行测试。测试完成根据《测试报告》由项目组内部讨论是否能生成新的版本。不通过则为无效版本,由开发人员再进行优化工作。更新记录过程中生成表格记录,审核通过后和源码一起打包受控形成外部版本。 内部版本外部版本优化内容优化记录记录人优化日期B1.1 V1.1 功能实现功能目 的性

相关文档
最新文档