文档库 最新最全的文档下载
当前位置:文档库 › 版本控制流程规范V0.1

版本控制流程规范V0.1

版本控制流程规范V0.1
版本控制流程规范V0.1

版本控制流程规范文

V0.1 档

目录

一、编写目的

4...

二、适用范围

4...

三、环境资源

5...

四、职责

5...

五、规范

6...

1,用户命名及权限配臵........................................................... 6. .

1)SVN 用户命名 (6)

2)访问约定 (6)

3)权限管理 (6)

2,SVN 库的划分........................................................... 7. ..

1) 版本库名 (7)

2) 文件结构 (7)

3,版本控制........................................................... 8. ..

1) 控制流程 (8)

2) 变更流程 (9)

4,备份方案.......................................................... 1.. 0.

一、编写目的

本文档主要目的是规范配臵管理活动的过程,阐述了在项目开发、测试、实施的过程中SVN 库的组成和使用规约,指导使用者正确地操作SVN 库,以保证项目中所产生的代码、文档各版本之间完整性、可追踪性和一致性。

适用范围

该规范适用于公司内部所有项目的配臵管理过程。

三、环境资源

在整个项目过程或产品生命周期中,选择SVN 作为配臵管理工具。

四、职责

五、规范

1,用户命名及权限配臵

1)SVN用户命名

项目组成员在各自的PC上安装SVN 客户端,根据配臵

管理员所分配的用户和权限登录配臵库进行各项配臵管

理活动。

初始用户命名规则:

用户名:公司邮箱@前的部分

密码:手机号后6 位

2)访问约定

为了保证各个项目组开发成果的安全性,以项目为单

位,进行了精确权限划分,使得成员只能操作该项目

组内的配臵项。

内网访问svn 资源库地址:

svn:https://... /svn/ 项目名称

3)权限管理

各个项目组成员只能访问、操作各自的项目库,并具有

特定文件区域的读、写权限,配臵管理员统一分配和管

理权限。

2,SVN 库的划分根据公司的项目,采用项目名—分区名—版本名—的主结构进行管理。

1)版本库名根据项目名称由项目经理与配臵管理员共同设

定。各项目统一建立 2 层目录,子目录根据实际情况

建立。

2)文件结构

a)工作区:按版本存放提交测试阶段的相关程序、文

档等

开发:开发相关

测试:测试相关

实施:实施运维相关

b)发布区:按版本存放已发布的相关程序、文档等

开发:开发相关

测试:测试相关实施:实施运维相关

结构图如下:

3,版本控制

1) 控制流程

a) 配臵管理员根据项目计划建立版本库并通知相关人

员(可根据情况确定建立时间);

b) 开发、测试、实施人员提交对应版本的程序与文档

到工作区目录下;

c)开发、测试人员根据测试情况更新工作区相关内容,

直到测试结束;

d)满足发布条件后,配臵管理员把工作区相关程序及

文档发布到发布区,并通知相关人员;

e)项目上线后实施人员提交实施相关文档,配臵管理

员放到对应版本的发布区内

2) 变更流程

a) 版本发布后如需修改,开发、测试、实施人员提

交变更申请给项目经理,并抄送配臵管理员,

内容包括项目名、版本、变更内容、变更原因、

变更时间、申请人等;

b) 项目经理审批通过后,由配臵管理员进行变更,

变更申请一同入库,并通知相关人员;

3)文件命名

根据版本程序或文档统一命名格式如下:

###V 0.0.0

版本号分3级,从左至右依次为1级、2级、3级,赋

值由项目经理定义:

第1级为主版本号,赋值范围1~99

第2级为分支版本号,赋值范围0~99

第3级为修改或升级版本号,赋值范围0~99

4,备份方案

每周五下午进行整体版本库的备份,目录结构按项目名

—年—月建立,存放至非SVN主机位臵,根据情况进

行刻碟备份。

软件开发流程管理制度

软件开发流程管理制度 (讨论稿) 为加强对定制软件开发工作管理,缩短开发周期,提高软件开发质量,降低开发成本,提高定开发效率和效益,特制定软件开发流程管理制度。 第一章、总则 为保证日常工作正常有序的进行,让开发中各个环境更紧凑,更可控,需要尽可能实现项目管理的正规化,工作过程的流程化,以便提高软件质量,按期交付。 1、软件开发总体遵循项目管理和软件工程的基本原则。 2、项目管理涉及项目立项、项目计划和监控、配置管理。 3、软件工程涉及需求分析、系统设计、软件实现、系统测试、用户测试、试运行、系统验收、系统上线和数据迁移、产品维护。 第二章、阶段成果 根据软件工程的过程,制定以下工作流程,并规定了各个重要环节需要提交的交付物。各阶段需提交的文档: 1、立项:项目申请表,软件需求报告或设计方案。 2、需求分析:项目研发主计划、需求规格说明书 3、总体设计:概要设计说明书或功能模块描述 4、详细设计:详细设计说明书,包括软件接口说明、单元测试计

划。 5、软件实现:软件功能说明、源代码说明或者注释 6、产品测试:测试报告 7、产品发布:产品说明书、使用手册 8、产品维护:问题反馈记录 9、项目总结:提交客户方的项目总结和公司项目汇报的PPT。软件过程成果表:

第三章、岗位设置 根据公司目前的开发过程主要分为分析、开发、测试三个阶段。分析阶段完成用户需求文档的编写,系统总体设计的编写;开发阶段完成设计文档的编写,代码的编写、代码的维护。测试阶段完成系统的测试,测试文档及其他材料。通过逐渐的调整岗位,明确工作职责,逐步实现项目经理,软件设计师,程序员,测试工程师的岗位设置。

版本控制流程规范V完整版

版本控制流程规范V HEN system office room 【HEN16H-HENS2AHENS8Q8-HENH1688】

版本控制流程规范文档 目录 一、编写目的 本文档主要目的是规范配置管理活动的过程,阐述了在项目开发、测试、实施的过程中SVN库的组成和使用规约,指导使用者正确地操作SVN 库,以保证项目中所产生的代码、文档各版本之间完整性、可追踪性和一致性。 二、适用范围 该规范适用于公司内部所有项目的配置管理过程。 三、环境资源 在整个项目过程或产品生命周期中,选择SVN作为配置管理工具。

四、职责 五、规范 1,用户命名及权限配置 1)SVN用户命名 项目组成员在各自的PC上安装SVN客户端,根据配置管 理员所分配的用户和权限登录配置库进行各项配置管理活 动。 初始用户命名规则: 用户名:公司邮箱@前的部分

密码:手机号后6位 2)访问约定 为了保证各个项目组开发成果的安全性,以项目为单位, 进行了精确权限划分,使得成员只能操作该项目组内的配 置项。 内网访问svn资源库地址: svn: ... /svn/项目名称 3)权限管理 各个项目组成员只能访问、操作各自的项目库,并具有特 定文件区域的读、写权限,配置管理员统一分配和管理权 限。 2,SVN库的划分 根据公司的项目,采用项目名—分区名—版本名—的主结构进行管理。 1)版本库名 根据项目名称由项目经理与配置管理员共同设定。各项目 统一建立2层目录,子目录根据实际情况建立。 2)文件结构 a)工作区:按版本存放提交测试阶段的相关程序、文档等 开发:开发相关 测试:测试相关

工艺流程+控制+方案

一、确定工艺流程:供料—— 圈圆——高频焊接——补涂——烘干 (1) 供料 ① 用机械手将一摞铁皮放置于托盘之上,由带有传感器发射器的机械托盘 带动铁皮上抬运输。 ② 如图1和图2.1所示,将铁皮升高至光电管处(光电管与吸盘为同一高度, 未画出),由带有吸盘的机械手吸起,放置Z 字形轨道进行圈圆。 ③ 如图2.1所示,若铁皮高度低于光电管时,反馈信号。由控制系统控制托 盘继续上移,光电管失去信号后1s ,停止上移。 ④ 如图2.2所示,此时红外测距传感器检测到托盘侧面的信号,反馈至控制系统。此时托盘下降至最低位置,由机械臂将新铁皮装入托盘。 (2) 圈圆 图2.1 托盘工作 图1. 工艺流程图 图2.2 上料

进入“Z”字形轨道将铁皮圈圆。由槽轮带动含吸铁石的轨道吸引前进,送至焊接处。 (3)高频焊接 ①用铜丝辅助对单张圈圆的铁皮进行电阻高 频焊接。 图3 电阻焊 ②如图3,由侧面推杆推桶底进入焊接位置由光电管检测,当进入被圈 圆的铁皮时反馈信号,进行焊接。等到焊接结束,由传送带传 动送至补涂处。 (4)补涂 ①焊接结束后由传送带运输,使用光电管控制,对桶外(内)壁进行补涂。 ②如图4,由光电管检测,当有桶时,反馈信号,喷头喷漆并由毛刷刷平。 图4 补涂 (5)烘干 使用链传动,18L方罐采用回转式的电磁烘干机进行烘干。送入下一阶段进行胀方。 二、控制要求 (1)伺服电机1工作,带动机械手(吸盘)移动到铁皮上方后下降至光电检测器1失去信号(此位置即吸盘与铁皮接触)。 (2)机械手上的气动装置打开,使吸盘吸附铁皮。 (3)机械手运动到滚轮下方(经过一个单张检测仪),气动装置关闭。 (4)机械手吸住铁皮运动至圈圆处,进入“Z”字形轨道

版本控制流程规范V0.1

版本控制流程规范文 V0.1 档

目录 一、编写目的 4... 二、适用范围 4... 三、环境资源 5... 四、职责 5... 五、规范 6... 1,用户命名及权限配臵........................................................... 6. . 1)SVN 用户命名 (6) 2)访问约定 (6) 3)权限管理 (6) 2,SVN 库的划分........................................................... 7. .. 1) 版本库名 (7) 2) 文件结构 (7) 3,版本控制........................................................... 8. .. 1) 控制流程 (8)

2) 变更流程 (9) 4,备份方案.......................................................... 1.. 0.

一、编写目的 本文档主要目的是规范配臵管理活动的过程,阐述了在项目开发、测试、实施的过程中SVN 库的组成和使用规约,指导使用者正确地操作SVN 库,以保证项目中所产生的代码、文档各版本之间完整性、可追踪性和一致性。 适用范围 该规范适用于公司内部所有项目的配臵管理过程。

三、环境资源 在整个项目过程或产品生命周期中,选择SVN 作为配臵管理工具。 四、职责

五、规范 1,用户命名及权限配臵 1)SVN用户命名 项目组成员在各自的PC上安装SVN 客户端,根据配臵 管理员所分配的用户和权限登录配臵库进行各项配臵管 理活动。 初始用户命名规则: 用户名:公司邮箱@前的部分 密码:手机号后6 位 2)访问约定 为了保证各个项目组开发成果的安全性,以项目为单 位,进行了精确权限划分,使得成员只能操作该项目 组内的配臵项。 内网访问svn 资源库地址: svn:https://... /svn/ 项目名称 3)权限管理 各个项目组成员只能访问、操作各自的项目库,并具有 特定文件区域的读、写权限,配臵管理员统一分配和管 理权限。

生产工艺流程控制的规程

生产工艺流程控制的规程(草稿) 一、目的 为加强企业的生产工艺流程控制,全面提升产品的制作质量,降低生产成本,各相关部门和人员按照优化5M1E(注1)的原则进行生产活动,增强企业的竞争力,特制订本规程。 ——注1:5M1E分别是英文-人员、机器、材料、方法、测量和环境的单词首位字母。 二、使用范围 本集团下属各公司的应依据本规程来制订、执改进行、生产工艺流程、对其结果进行考核、奖惩,除另有规定外,均以本规程执行; 三、规程的内容: 1、工艺流程涉及的部门(体系化) 工艺流程涉及的部门有:各公司的技术部、生产部、质检部、和集团采购部。 2、管理责任(制度化) (1)各公司技术部责任 a,制定合理的工艺流程文件 各公司的技术部依据产品任务单,制定生产工艺流程的文件,工艺流程文件的主要是以下三种类: ——工艺过程卡片;

——工序卡片; ——操作说明书; 工艺流程的卡片和操作说明书中应包含:图纸(加工的工件图纸以及关键步骤和重要环节都有图纸说明)、加工工序、加工方法及对环境的要求、检验及方法、产品的包装、工时定额、材料和物耗定额、使用的设备和工装、加工工具、对特殊工件的吊装位置及方法、包装方法、加工的起始时间、责任者的签名等,总之应当是实际工作中涉及的工序和各个工序中要点(5M1E)都要简约地反映在流程中;——注2:工时定额和物耗定额:在实际中灵活应用和执行,对于首件和单件生产可以是定性管理;对于3-5件的小批量生产应当是首件完成后,对出其余件进行的半定量管理,就是给个范围值;对于成熟的大批量生产件应当是定量管理,就是应当给出固定的定额;——注3:可以有空项,按实际生产中需要的项目编写,应当简要全面部不应当有漏项;各个公司在制定工艺流程时,可以是表格式、卡片式、文字表述式,只要能在实际生产中,对生产的产品有以下作用即可--加工的指导、检验指导、记录完整(可以追溯产品的加工历史);b,根据生产出现的问题,可以用工艺流程附加单的形式进行补充及修改,必要时废除老工艺,重新制定新工艺; c,会同质检部门处理质量异常问题。 (2)各公司生产部责任

测试流程版本管理规范标准[详]

测试流程、版本管理规 编制: 审核: 批准: 文件历史记录

目录 测试流程、版本管理规 (1) 1.目的 (3) 2.适用围 (3) 3.测试流程规 (3) 3.1搭建环境 (3) 3.2冒烟测试 (3) 3.3禅道版本管理规 (3) 3.4系统测试流程规 (4) 3.6 缺陷管理流程 (8) 3.4上线版本 (9) 4.系统版本管理规 (9) 1.目的 为了规项目组的测试流程、版本规,减少人为影响上线版本的质量 2.适用围 项目组所有系统以及流程的版本 3.测试流程规 3.1搭建环境 缺失本次版本变更说明或者部署文档不完整,需向开发人员说明,并要求提供齐全,保证文档有效性。

3.2冒烟测试 ?环境搭建完后,进行冒烟测试,如果冒烟测试不通过,需打回版本 ?如果未实现需求涉及的功能,打回版本(除非开发人员有说明按模块提交测试)3.3禅道版本管理规 产品 ?接到新的系统时,首先在产品模块新建产品名称,命名规则直接以系统名称为准,比如“移动OA” ?产品新建成功后,需要把需求关联至产品,可以直接把文档或者git地址关联进来 项目 ?新项目或者目前版本的变更时,需要新建项目,项目需要关联产品,命名规则直接以版本名称为准,比如“移动OA3.0” ?项目新建成功后,开发提交一次版本,需要把版本号进行维护,版本号命名规则。如“移动OA3.0_rc1”,以此类推,每一轮测试时,如果仍存在BUG,需要把下个版本号提前维护进来,方便开发变更BUG状态时,选择正确的版本号 测试 ?项目的模块需要分类维护,测试用例对应到模块下,每一轮测试完毕后,需要变更测试用例状态,并把测试用例与BUG进行关联 ?在测试过程中,如果测试用例有遗漏,需要补写 ?每一轮测试结束后,需要出测试报告

软件配置管理规范流程

1 概述 1.1 目的 本文档主要目的在于规范项目配置管理活动,确保配置项正确地唯一标识并且易于存取,保证基线配置项的更改受控,明确基线状态,在整个软件生命周期中建立和维护项目产品的完整性和可追溯性。 1.2 适用范围 本文档适用于不同类别的软件产品和软件项目开发工程的配置管理活动,针对项目不同在流程上作适当的删减。配置管理可采用各种工具及手工办法,本文件以CVS(并行版本系统)配置管理工具为例,规定公司的配置管理办法,使用其他工具时也可对应本文件的要求参照执行。 1.3 术语和缩略语 1.3.1 软件配置管理(Software Configuration Management,SCM) 软件配置管理是对软件修改进行标识、组织和控制的技术,用来协调和控制整个过程。是通过技术或行政手段对软件产品及其开发过程和生命周期进行控制、规范的一系列措施。配置管理的目标是记录软件产品的演化过程,确保软件开发者在软件生命周期中各个阶段都能得到精确的不同版本的产品配置。 1.3.2 配置项(Configuration Item,CI) 凡是纳入配置管理范畴的工作成果统称为配置项,配置项逻辑上组成软件系统的各组成部分,一般是可以单独进行设计、实施和测试的。 每个配置项的主要属性有:名称、标签、文件状态、版本、作者、日期等。所有配置项都被保存在配置库里,确保不会混淆、丢失。配置项及其历史记录反映了软件的演化过程。 1.3.3 基线(Baseline) 在配置管理系统中,基线就是一个配置项或一组配置项在其生命周期的不同时间点上通过正式评审而进入正式受控的一种状态,这些配置项构成了一个相对稳定的逻辑实体,而这个过程被称为“基线化”。每一

产品开发版本管理流程

版本管理流程 1.0目的 本流程旨在对产品版本实施有效的管理与控制,从而进一步实现产品开发的工程化和系统化,提高产品开发的质量管理水平,以保证产品开发的规范性和继承性。 2.0范围 本流程适用于开发设计的硬件产品、软件产品、产品的测试工具及顾客系统。 3.0定义 3.1版本 本文中的版本,包括如下几个范畴: ●内部验收通过后的实验版本,用于小批量试产及现场试验; ●正式验收通过后的正式版本。 3.2版本库 技术管理部版本管理员必须建立二个版本库,用以保存已正式运行的所有版本,以便发现问题时能及时进行问题的定位。这两个版本库为: (1)产品版本库:为满足一般顾客需求的版本。 (2)专用版本库:为满足某些顾客的特殊需求而定制的专用版本。这种版本应尽量减少, 当某些需求已成为一种较为普通的需求时,应考虑将该功能在通用版 本中实现。 为方便管理,开发部门在产品开发过程中可自行定义一些临时版本及建立本部门的开发版本库,开发部的临时版本库为开发版本库,技术支持部的临时版本库为顾客版本库。 4.0职责 4.1技术管理部版本管理员 4.1.1建立及管理产品版本库、专用版本库,控制版本的发行; 4.1.2控制版本的升级; 4.1.3负责发布产品的《版本说明及配套表》。 4.2开发部、技术支持部经理 4.2.1负责产品问题的定位; 4.2.2与项目组一起确定设计更改及工程更改方案;

4.2.3审核《设计(工程)更改报告》、《版本说明及配套表》及监督文档更新。 4.3项目组/项目负责人 4.3.1负责系统联调过程中问题的收集; 4.3.2负责产品的设计更改、工程更改并编制相应文档; 4.3.3负责对产品所作的更改进行测试并编制相应的文档。 4.4技术管理部测试组 负责对产品所作的工程更改进行验收测试并编制《验收测试报告》。 4.5总工程师 4.5.1负责批准设计更改申请和《设计(工程)更改报告》; 4.5.2负责批准《版本说明及配套表》。 4.6开发部门版本管理员 负责根据技术管理部分配的版本号及归档的技术文档对版本进行定义并编写产品的《版本说明及配套表》。 5.0流程提要 开发部门根据各方面反馈的产品质量问题,首先定位问题所对应的版本库及版本,然后确定相应的更改方案,在此基础上,根据具体情况进行设计的更改、测试、内部验收、小批量试产、现场试验及正式验收等阶段,开发出实验版本或正式版本,用于向市场发布。 6.0流程说明 6.1建立产品版本库、专用版本库 技术管理部的版本管理员根据项目情况建立产品版本库和专用版本库。 6.2根据反馈的问题定位相应版本库及版本,确定更改方案。 总工程师、开发部门及技术管理部版本管理员根据产品的《验收测试报告》、《产品小批量试产报告》、顾客反馈意见以及内部升级需求,针对所反馈的问题,定位相应的版本库及版本,对问题定位并确定设计更改或工程更改的方案,技术管理部版本管理员分配一个新的版本号,以、《预研(项目)任务书》及《研发任务书》的方式作为产品或系统更改、升级及换型的依据。 6.4设计更改及测试 开发部门根据《预研(项目)任务书》及《研发任务书》实施产品/系统的工程更改、升级及改型,之后进行单元测试、集成测试及系统联调测试,联调通过后修改相应的技术文档,编写《设计(工程)更改报告》等相应的技术文档。

软件项目上线标准流程

项目上线部署发布流程

2017/9/14

一.目的 规范公司项目和产品的上线流程,建立和完善产品的版本控制,保证软件产品质量。二.适用范围 适用于公司所有项目和产品 三.职责分工 开发环境由开发人员内部负责(包括维护和管理开发分支和git代码库) 测试环境由测试人员负责 预热环境由运维人员负责 正式环境由运维人员负责 *数据库操作均由DBA统一负责(或运维人员) 四.发布流程 在已开发完毕的各系统正式部署生产环境前要严格按照以下流程进行上线前检查。 4.1.提交测试 ①开发人员在功能开发完毕后首先配置开发环境,并将系统部署至开发环境。在开发环境经过自测通过后提交测试代码,并开始撰写上线方案。(上线方案须包括新增的外部应用程序安装,应用程序部署顺序及应用关联性、是否关闭其他应用服务,数据库脚本,制定合理的上线时间,涉及的服务影响范围以及上线失败的回滚步骤。)并提交相关技术负责人审核,在审核过后邮件给相关测试人员。 ②测试人员根据模块功能文档并制定测试方案,测试用例,特别注意临界点测试方案。 ③测试人员通过自动化部署平台根据提供的分支号依照上线方案进行自动化部署,涉

及数据库操作可提请DBA操作。 ④记录各种数据测试结果及测试问题,并交由相关开发人员进行二次迭代处理,该点须交付测试结果报告。 ⑤内测完毕后交由相关业务及需求人员进行集成测试,并请测试人员记录测试结果及问题,交由相关开发人员进行再次迭代。该点须交付测试方案测试结果报告。 4.2.预热发布 ①测试人员在测试环境测试并跟踪修改bug达到上线标准(没有A、B级bug,C 级bug达到要求)时。开始部署预热环境,测试人员对现有功能在预热环境上进行验收测试(重新执行case)。紧急Bug修改走补丁/hotfix流程。不影响功能的bug留到下次版本解决,确认达到上线标准。 ②如达到上线标准,测试人员发起邮件通知相关开发人员、产品人员,准备正式上线发布流程。 4.3.正式上线 ①在测试人员确认项目具备上线条件下,正式上线前,开发负责人须发起部署大会,召集相关开发人员、测试人员、产品人员、运维人员讨论此次部署事项(介绍项目的相应负责人员,数据库脚本执行,部署顺序,应用程序关联,部署时间点,部署回滚方案,包括数据库回滚和应用程序回滚),最后生成会议纪要并发送邮件。 ②确认上线之后,测试人员邮件上线方案,数据库脚本,应用分支号给运维人员及DBA,DBA应提前执行数据库脚本,应用部署须通过自动化部署平台进行部署,部署系统应在应用系统中记录当前分支号,以便后续应用回滚使用。在部署中出现错误,及时通知相关开发人员。如若问题不能在计划内时间解决,执行回滚方案。 ③运维,DBA在操作完成时均需要回复邮件,并说明操作步骤结果。 ④发布完成后运维人员回复邮件通知测试人员、业务及需求人员进行线上测试。测试结果及问题, 提交至开发人员。如若出现问题不能在计划内时间解决,执行回滚方案,并进行迭代改进。 ⑤紧急Bug修改走补丁/hotfix流程。不影响功能的bug留到下次版本解决。测试通

软件产品发布流程

严格按照软件产品发布流程发布软件版本是建立和完善软件产品版本控制,保证软件产品质量的关键过程 之一。 参与软件产品发布的人员主要是测试负责人和BM(Build Master)。 公司软件产品发布的规程如下: 1、发布准备。发布之前,所有程序freezed由测试人员进行确认测试;检查qcs系统内登记的所有bug都已经被fixed,或者遗留的bug不影响系统的使用,如果有严重bug未解决(级别为must fixed)不能发布;程序打包前做冒烟测试。 2、测试负责人编写release产品质量报告进行质量分析和总结。 3、源码、文档入库。源码包括数据库创建脚本(含静态数据)、编译构建脚本和所有源代码;文档包括需求、设计、测试文档,安装手册、使用手册、二次开发手册、产品介绍(ppt)、使用demo等。 4、BM进行程序打包;标记源码、文档版本tag。 5、BM填写发布基线通知并通知相关人员;BM经理对发布基线进行审计。 6、在qcs系统上新建产品发布计划,填写配置项,执行发布计划(发布产品)。 7、上传程序包、使用文档至download站点。 8、编写发布说明readme.txt(或者release note)。Readme的内容应该包括产品版本说明;产品概要介绍;本次发布包含的文件包、文档说明;本次发布包含或者新增的功能特性说明;遗留问题及影响说明;版权声明以及其他需要说明的事项。 9、正式发布通知。通知开发、测试、市场、销售各相关部门并附上产品发布说明和产品介绍。

10、后续工作。产品发布后,在使用过程中可能还会发现一些bug。在不影响正常使用的情况下,这些bug将在下一版本发布时解决;如果bug严重影响使用,必须打patch或者按照流程重新发布。 11、临时发布。软件产品未正式发布前,可能需要一个临时版本供开发人员或者用户应急使用,这时候需要临时发布一个版本。这个版本只包括基本的程序包和必要的使用说明。临时发布需要通知相关开发、测试人员;BM需要为源码、文档打tag标记。 软件产品发布后,即建立了一条发布基线。所有用户安装及二次开发必须在此基线上进行,开发人员不能直接从cvs或vss上check 代码编译交付用户使用或者进行二次开发。

机械滑台工艺流程控制系统设计

电气与自动化工程学院实训评分表 课程名称: PLC控制技术实训 实训题目: 机械滑台工艺流程控制系统设计 班级:电气101 学号:160710118 姓名: 陆敬博 指导老师:许仙珍 2013年7 月 4 日

常熟理工学院电气与自动化工程学院 《PLC控制技术实训》 题目:机械滑台工艺流程控制系统设计 姓名: 陆敬博 学号: 160710118 班级:电气101 指导教师: 许仙珍 起止日期: 2013.6.24----2013.7.2

目录 1.设计任务书…………………………………………………………1 1.1设计任务 1.2设计目的及要求 1.3 设计内容及报告要求 2基础实训项目一: (2) 2.1I/O地址分配表 2.2程序 3基础实训项目二: (5) 3.1 I/O地址分配表 3.2程序 4.综合型自主实训项目 (10) 1.总体设计方案 1.1 方案的确定 1.2 设计方案 2.I/O地址分配表 2.1 I/O模块的地址分配 3.顺序功能图,梯形图及指令表 3.1顺序功能图 3.2 梯形图 3.3程序说明 4.程序的调试运行及其结果

4.1 手动控制的调试运行及结果 4.2单步控制的调试运行及结果 4.3 自动循环控制的调试运行及结果 5.个人小结......................................................296.参考文献 (30)

一.任务书 《PLC控制技术》实训任务书 题目:机械滑台工艺流程控制系统设计(三) 实训学生需要完成2个基础实训项目和1个综合型自主实训项目的训练。 一、基础实训项目一:霓虹灯的PLC控制系统的设计 一)实训目的 1、进一步巩固掌握PLC基本指令功能的及其运用方法; 2、根据实训设备,熟练掌握PLC的外围I/O设备接线方法 3、初步掌握PLC程序设计方法,养成良好的设计习惯,培养基本的设计能力; 二)实训设备: 三相交流电源模块30822001、直流电源模块30824001、PLC主机单元模块30864002、数字量输入模块30824003、霓虹灯显示模块18504003、个人计算机PC、PC/MPI编程电缆。 三)工艺控制要求: 按下启动按钮,灯A亮1秒,接着灯B,C,D,E,F,G,H,I亮1秒,之后灯J1,J2,K1,K2,L1,L2,M1,M2, N1,N2,O1,O2也被点亮。1秒后,灯J1,J2,K1,K2,L1,L2,M1,M2,N1,N2,O1,O2熄灭,再过1秒,灯B,C,D,E,F,G,H,I熄灭,同样再过1秒后,灯A熄灭。紧接着过1秒灯A再次被点亮,重复以上过程,循环往复。按下停止按钮后,所有灯都熄灭。 四)实训内容: 1、进行PLC的I/O地址分配,并画出霓虹灯的PLC控制系统的接线图。 2、设计由PLC 控制的霓虹灯梯形图程序。 3、输入自编程序,上机调试、运行直至符合动作要求。 二、基础实训项目二:模拟量采集与数据处理的综合应用 一) 实训目的 1、掌握PLC中模拟量输入、输出的基本工作原理。 2、掌握数据处理指令的运用方法。 3、掌握功能、功能块的应用,中断组织块OB35用法。 4、掌握DB块建立与数据访问方法。 二)实训设备: 三相交流电源模块30822001、直流电源模块30824001、PLC主机单元模块30864002、数字量输入模块30824003、模拟量输入模块、模拟量输出模块、个人计算机PC、PC/MPI 编程电缆。 三)实训项目原理与要求 1、用模拟量输入模块3081400模拟温度测量变送器,假设当温度是0℃时,对应电位器输出0V电压,假设当温度是100℃时,对应电位器输出电压10V电压。用PLC模拟量输入模块采集电位器电压,使用OB35实现采集温度数据,数据采集频率是1次/秒,进行标度变换,数据存储在共享数据块DB2相应

产品版本管理规范

基于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. 文档 一种数据媒体和其上所记录的数据。

版本控制工具使用规范.

版本控制与code review规范 目录 branch使用规则 (3 公共branch命名示例 (3 个人branch命名示例 (3 个人branch创建规则 (3 代码提交流程 (3 Windows平台文件夹方式操作与建议 (4 个人branch创建操作 (4 个人branch代码提交 (6 merge操作 (9 操作步骤1:合并branch (9 操作步骤2:解决冲突 (12 Eclipse 插件方式操作与建议 (14 Mac平台操作与建议 (21 1.采用CornerStone客户端进行SVN操作 (21 1、与服务器创建连接 (21

2、个人branch创建操作 (22 3、把服务器上个人branch 进行check out 到本地 (24 4、个人branch提交(commit操作 (25 5、merge操作 (26 2.采用终端命令提示符进行SVN操作 (28 1、将文件checkout到本地目录 (28 2、往版本库中添加新的文件 (29 3、将改动的文件提交到版本库 (29 4、加锁/解锁 (29 5、更新到某个版本 (29 6、查看文件或者目录状态 (30 7、删除文件 (31 8、查看日志 (32 9、查看文件详细信息 (32 10、比较差异 (32 11、将两个版本之间的差异合并到当前文件 (34 12、SVN 帮助 (35 13、版本库下的文件和目录列表 (35 14、创建纳入版本控制下的新目录 (36

15、恢复本地修改 (36 16、代码库URL变更 (36 17、解决冲突 (37 18、输出指定文件或URL的内容。 (37 branch使用规则 公共branch命名示例 branch-20150326-candidate 个人branch命名示例 branch-20150326-hulanlan branch-20150326-taskID 个人branch创建规则 ●开发人员基于每个开发小任务创建自己的branch, 以每天check in 自己的代码作备份。 ●基本原则是从最新代码创建branch,以方便未来的代码合并 ●原则是不直接在服务器上操作 代码提交流程 1.测试本地代码 2.整理本地代码, 申请code review 3.提交本地代码到个人branch

机械滑台工艺流程控制系统设计

电气与自动化工程学院实训评分表 课程名称:PLC控制技术实训 实训题目:机械滑台工艺流程控制系统设计 班级:电气101 学号:160710118 姓名:陆敬博 指导老师:许仙珍 2013 年7 月 4 日

常熟理工学院电气与自动化工程学院 《PLC控制技术实训》 题目:机械滑台工艺流程控制系统设计 姓名:陆敬博 学号:160710118 班级:电气101 指导教师:许仙珍 起止日期:2013.6.24----2013.7.2

目录 1.设计任务书 (1) 1.1 设计任务 1.2 设计目的及要求 1.3 设计内容及报告要求 2基础实训项目一: (2) 2.1 I/O地址分配表 2.2 程序 3基础实训项目二: (5) 3.1 I/O地址分配表 3.2 程序 4.综合型自主实训项目 (10) 1.总体设计方案 1.1 方案的确定 1.2 设计方案 2. I/O地址分配表 2.1 I/O模块的地址分配 3.顺序功能图,梯形图及指令表 3.1 顺序功能图 3.2 梯形图 3.3 程序说明

4.程序的调试运行及其结果 4.1 手动控制的调试运行及结果 4.2 单步控制的调试运行及结果 4.3 自动循环控制的调试运行及结果 5.个人小结 (29) 6.参考文献 (30)

一.任务书 《PLC控制技术》实训任务书 题目:机械滑台工艺流程控制系统设计(三) 实训学生需要完成2个基础实训项目和1个综合型自主实训项目的训练。 一、基础实训项目一:霓虹灯的PLC控制系统的设计 一)实训目的 1、进一步巩固掌握PLC基本指令功能的及其运用方法; 2、根据实训设备,熟练掌握PLC的外围I/O设备接线方法 3、初步掌握PLC程序设计方法,养成良好的设计习惯,培养基本的设计能力; 二)实训设备: 三相交流电源模块30822001、直流电源模块30824001、PLC主机单元模块30864002、数字量输入模块30824003、霓虹灯显示模块18504003、个人计算机PC、PC/MPI 编程电缆。 三)工艺控制要求: 按下启动按钮,灯A亮1秒,接着灯B,C,D,E,F,G,H,I亮1秒,之后灯J1,J2,K1,K2,L1,L2,M1,M2, N1,N2,O1,O2也被点亮。1秒后,灯J1,J2,K1,K2,L1,L2,M1,M2,N1,N2,O1,O2熄灭,再过1秒,灯B,C,D,E,F,G,H,I熄灭,同样再过1秒后,灯A熄灭。紧接着过1秒灯A再次被点亮,重复以上过程,循环往复。按下停止按钮后,所有灯都熄灭。 四)实训内容: 1、进行PLC的I/O地址分配,并画出霓虹灯的PLC控制系统的接线图。 2、设计由PLC 控制的霓虹灯梯形图程序。 3、输入自编程序,上机调试、运行直至符合动作要求。 二、基础实训项目二:模拟量采集与数据处理的综合应用

版本管理规范

版本管理规范 一、版本管理办法 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.修改后的文件及文件夹的名字,跟修改前的必须同名,否则识别不了,当成新增

版本控制说明

Svn 版本控制 1、版本控制的必要性 版本控制(Revision control)是一种软体工程技巧,籍以在开发的过程中,确保由不同人所编辑的同一档案都得到更新。 就以软件开发来说,在开发过程中,利用svn进行版本控制可以帮助你记录你的开发过程,例如在某个时间段项目进行到了哪一步,还有哪些没有开发;哪些人参与了哪一模块的开发等,这样开发过程中如果出现问题也能够很快找到相应的负责人,得到最快解决,也能够及时协调开发过程中人力资源的合理分配。利用版本控制,可以有效地实现并行开发,不同的开发模块可以同时进行开发,防止重复开发和更改覆盖的现象,即使更改被覆盖也可以利用svn的恢复技术,恢复到未出错之前,能够减少开发风险。 利用版本控制开发的项目能够很容易的看出哪个是当前的最新的版本,以及每个版本的改进之处或者说解决了哪些问题,而且对于软件测试来说,版本控制能让你知道哪里改变了,以及代码的变化带来的影响,在知道具体内容后也就能省去一些无用的调试。 2、什么是版本控制? 版本控制系统是一个当你在开发一个程序时存储你写的东西的所有修订版本的地方。 1)项目仓库 项目仓库是存储存储各种版本项目文件的主要地方,需要存储什么?一条判断准则:如果没有这个文件的最新版本,我们是不是可以构建、测试并交付我们的程序! 2)版本编号:具体文件编号和项目仓库整体编号 3)项目、目录和文件 4)标签 5)分支 2、版本控制的实现方案 版本控制有两种实现方案: 一种是The Lock-Modify-Unlock Solution(锁-修改-解锁的解决方案); 在这种方案下,每次只允许一个用户去进行修改,当用户要对文件进行修改时,必须先锁定该文件,此时其他用户就不能对文件进行修改了,只有当当前用户修改完文件,解锁该文件后,其他用户才能对该文件进行修改操作。 该方案有以下缺点: 1)一旦用户在修改完文件后忘记解锁该文件,那么其他用户将永远不能或者通过其他方法解除该锁后修改文件,这会造成延时或者资源浪费。 2)当一个用户只修改文件的前半部分,而另外一个用户修改文件的后半部分,他们所要操作的内容并没有交集,他们可以分别同时进行修改然后将修改内容合并,完全没有必要按先后顺序依次进行修改 3)安全性 另外一种是The Copy-Modify-Merge Solution(复制-修改-覆盖的解决方案),目前的版本控制软件主要是以后者为主,一些特殊情况下采用前者进行版本控制。

干化系统工艺流程及说明

1. 干化系统工艺流程及说明 1.1工艺流程框图 1.2分系统工艺流程及说明 1.2.1湿污泥接收、储存及给料系统 1.2.1.1系统工艺路线

1.2.1.2 系统概述 本项目污泥总处理能力450 t/d ,一期工程处理能力300 t/d ,污泥接收转运系统按450 t/d 设计。 污泥经由卡车运输至本系统,首先卸料至污泥接收钢仓。为保证卸料过程的污染,本方案采取如下卸车程序:运输车达到接收间大门前,大门打开,当运输车全部进入接收间后,大门关闭,接收间厂房臭气收集系统开启,接收仓液压盖板开启,卸车。卸车完毕后,仓盖板关闭,厂房大门开启,自卸车驶出,厂房大门关闭,接收间厂房臭气系统在1小时后关闭。 污泥接收仓采用矩形地下料仓形式,污泥进入接收仓后,液压驱动破拱滑架在仓底往复运动,阻止污泥在卸料区架桥,并连续不断地将污泥输送至仓底液压双轴螺旋输送机。接收仓配有在线超声波料位计,进行料仓监控。液压双轴螺旋输送机在接收到破拱滑架输送来的污泥后,以增压方式,向液压柱塞泵喂料。 根据本工程规模,共设置2套地下式污泥接收系统。每套接收仓系统配有一座接收仓、2个进泥液压门、1套滑架、2台液压双螺旋卸料机(一用一备)、2台柱塞泵(一用一备)、2套液压站(与柱塞泵对应,一用一备)。每个接收仓的有效容积为100m 3。柱塞泵采用一用一备,为配合热备柱塞泵切换,污泥分配系统通过电动闸板阀配合泵故障信号进行备用泵切换。液压柱塞泵在接收到污泥后,通过管道泵送至污泥储存仓。柱塞泵后布管采用总管方式。管道安装有阀门系统,通过阀门调配,实现备用泵管道切换和进料储仓切换。 每个储存仓有效容积为400m 3,近期设3座。储存仓接收到泵送来的污泥后,通过仓底往复运动的液压破拱滑架,防止污泥在卸料区形成架桥,并连续不断将污泥输送至仓底电动单轴卸料螺旋,并最终将污泥输送至干化机喂料螺杆泵。每台干燥机分别可以接收来自两座湿污泥储存仓的污泥,这样既可以实现螺杆泵的备用,也可以实现仓的备 湿污泥含 水率75%

软件版本管理文档

文档编号: 编制:杨忠林 审核: 批准: 目录

1引言 (3) 目的 (3) 范围 (3) 术语定义 (3) 版序控制记录 (4) 版本更新记录 (4) 2版本管理 (4) 流程图 (4) 版本命名 (7) 外部版本命名说明 (7) 内部版本命名说明 (7) 内外部版本的关系 (7) 版本升级 (7) 版本升级原则 (7) 新版本的发布 (8) 目录结构 (8) 文档的存放 (9) 文本文件的存放 (9) 源代码的存放 (9) 发行文档的存放 (9) 权限控制管理 (10) 3备份管理 (10) 源文件备份 (10) 库文件备份 (10) 4用户版本管理 (10) 5版本工具的使用 (11) 配置管理工具 (11) SVN的使用 (11) 常用命令 (11) 简单操作 (12) 版本分支管理 (12)

1引言 1.1目的 本文档是为规范xxxx科技有限公司软件版本管理而制定的。 1.2范围 本文档为系统软件开发部版本管理员提供有关版本管理规范的相关内容,包括:版本标识方法 软件系统数据的存放 文档的修改控制 文档的备份制度 1.3术语定义 SVN SVN是一个开源的版本控制系统 Subversion 的简称 文档 一种数据媒体和其上所记录的数据。 配置管理 标识和确定系统中配置项的过程,在系统整个生存周期内控制这些项的投放和更动,记录并报告配置的状态和更动要求,验证配置项的完整性和正确性。 软件配置 软件的具体形态在某时刻的瞬时影像。 配置项 软件配置管理的对象称为配置项,如:系统规格说明书,项目开发计划,用户手册,源码。 基线 软件生存周期中各开发阶段末尾的标记,它的作用是把各阶段工作的划分更加明确化,使本来连续的工作在这些点上断开,使之便于检验和肯定阶段成果。

全流程自动化控制系统设计方案.doc

全流程自动化控制系统设计方案 .安徽罗河铁矿选矿全流程自动化控制系统设计方案烟台金建设计研究工程有限公司二〇〇九年八月罗河铁矿选矿全流程自动化控制系统设计方案word 资料.目录前言……………………………………………………………………1一. 公司简介21.公司概况22.工程业绩表4二.设计概要81.设计依据82.设计原则83.设计目标9三. 系统设计111.系统构成111.1过程控制系统111.2网络通讯系统131.3网络数字监控系统132.监控及操作设计142.1上位机监控142.2系统操作163.过程控制设计173.1破碎过程自动控制系统173.1.1工艺过程173.1.2控制思想183.1.3系统控制方案193.2 磨选及浓缩过程自动控制系统223.2.1工艺过程分析223.2.2 控制思想253.2.3系统控制方案283.3 恒压供水控制434.控制系统主控单元444.1硬件设计444.2 软件设计474.3 控制设备选择524.4 系统其它设计535.多媒体电视监控系统555.1系统优势555.2 设计原则575.3 系统功能585.4系统构成595.5系统设计方案62四. I/O点统计65五. 设备表86word 资料前言冶金行业的选矿厂工艺流程包括破碎、筛分、磨矿和选别等几个主要生产过程,国内大多数矿山存在生产环境恶劣、自动化水平较低,磨机给料采用手动给矿,人工观察出矿浆粒度、浓度,根据人工判断磨机负荷对给矿机的运行状况和水路进行调节。 由于调节不及时,运行不稳定,常常使磨机出现“空腹”或“胀肚”的现象,影响整个磨选工艺流程的稳定性。因此,对选矿厂实施

测试流程版本管理规范

测试流程、版本管理规范 编制: 审核: 批准: 文件历史记录

目录 测试流程、版本管理规范 (1) 1.目的 (2) 2.适用范围 (3) 3.测试流程规范 (3) 3.1搭建环境 (3) 3.2冒烟测试 (3) 3.3禅道版本管理规范 (3) 3.4系统测试流程规范 (4) 3.6 缺陷管理流程 (5) 3.4上线版本 (8) 4.系统版本管理规范 (10) 1.目的 为了规范项目组的测试流程、版本规范,减少人为影响上线版本的质量

2.适用范围 项目组所有系统以及流程的版本 3.测试流程规范 3.1搭建环境 缺失本次版本变更说明或者部署文档不完整,需向开发人员说明,并要求提供齐全,保证文档有效性。 3.2冒烟测试 环境搭建完后,进行冒烟测试,如果冒烟测试不通过,需打回版本 如果未实现需求涉及的功能,打回版本(除非开发人员有说明按模块提交测试) 3.3禅道版本管理规范 产品 接到新的系统时,首先在产品模块新建产品名称,命名规则直接以系统名称为准,比如“移动OA” 产品新建成功后,需要把需求关联至产品,可以直接把文档或者git地址关联进来 项目 新项目或者目前版本的变更时,需要新建项目,项目需要关联产品,命名规则直接以版本名称为准,比如“移动OA3.0” 项目新建成功后,开发提交一次版本,需要把版本号进行维护,版本号命名规则。如“移动OA3.0_rc1”,以此类推,每一轮测试时,如果仍存在BUG,需要把下个版本号提前维护进来,方便开发变更BUG状态时,选择正确的版本号 测试 项目的模块需要分类维护,测试用例对应到模块下,每一轮测试完毕后,需要变更测试用例状态,并把测试用例与BUG进行关联 在测试过程中,如果测试用例有遗漏,需要补写 每一轮测试结束后,需要出测试报告

相关文档