软件发布管理流程规范

软件发布管理流程规范本文旨在规范软件发布管理流程，确保软件发布过程的可控性和规范性。2.发布流程为了保证软件发布的质量和效率，本文规定了补丁发布流程、主版本发布流程、产品实施流程和VSS管理流程。2.1.补丁发布流程补丁发布流程包括需求分析、设计、开发、测试、审核、发布和验证等环节。其中，审核环节需要由专门的审核人员进行审核，确保补丁的质量和安全性。2.2.主版本发布流程主版本发布流程包括需求分析、设计、开发、测试、审核、发布和验证等环节。在审核环节中，需要对软件进行全面的测试，确保软件的稳定性和兼容性。2.3.产品实施流程产品实施流程包括需求分析、设计、开发、测试、审核、发布和培训等环节。在审核环节中，需要对产品进行全面的测试，确保产品的质量和可用性。2.4.VSS管理流程VSS管理流程包括版本控制、变更管理、文档管理、缺陷管理等环节。在版本控制和变更管理环节中，需要对代码进行严格的管理，确保代码的稳定性和安全性。3.相关资料本文所需的相关资料包括需求文档、设计文档、测试文档、审核记录、发布记录等。这些资料需要进行有效的管理和归档，以便于后续的查阅和追溯。4.总结本文制定了一套完整的软件发布管理流程规范，旨在提高软件发布的质量和效率，确保软件发布过程的可控性和规范性。同时，需要保证相关资料的有效管理和归档，以便于后续的查阅和追溯。补丁发布流程规范该文档规范了补丁发布的流程，下图中每个方框代表一个进程，括号内描述该进程的具体内容。每个进程均要求相应职位填写《补丁签发单》。需求组：开始开发部：开发部经理接收任务，安排开发人、预计开发完成时间，并通知SCM。配置管理员测试组提出变更请求：事先征得需求澄清会的同意，再填《补丁签发单》，并通知开发经理。检查：检查前两个环节填写的签发单是否符合填写要求；检查描述是否清晰、时间要求有无冲突。如果检查未通过，需要重新填写签发单。如果检查通过，需要安排补丁号，发布日期，通常将完成时间相距不远的安排在同一补丁号中。同时设置VSS权限，根据开发部经理的安排设置，并通知相关人，开始执行施变更，并公布预计发布日期、实施建议。开发人：执行变更（按照要求修改代码、文档，并按规范存放）。测试组长：制定测试计划（按照签发单，安排测试人、预计测试完成时间）。产生alpha版（开发部内部可产生多个alpha版），并安装alpha测试环境。部门内部测试：alpha阶段的测试，相当于单元测试，并通知SCM。如果测试未通过，需要重新修改并进行测试。如果测试通过，则需要产生Beta版。产生Beta版：检查相关文档是否已备齐；根据签发单，检查当前补丁号中提出的变更是否都已执行；检查开发人在CheckIn/out的过程中，是否符合VSS管理规范、版本管理规范；根据签发单，制作补丁发行说明；关闭VSS权限；编译构建beta版；通知测试组、安装组，向其提交该补丁的书面签发单。安装Beta测试环境：编写/更新补丁安装手册；选择测试环境，安装补丁beta版；通知测试组、相关人，同时刷新“公司内部产品试用环境一览表”白板。验收测试：beta阶段的测试，相当于集成测试；通知相关人测试结果，含邮件、签发单电子格式的回复。若测试通过，则还包括在书面签发单上签名。如果测试未通过，需要重新修改并进行测试。如果测试通过，则需要产生Release版。Release阶段：检查测试结果是否已全部通过；检查提交文档是否已齐全；标识、备份、记录。通知相关人。详见：《版本发布前的checkList》。分发Release版根据安装组的工作计划和各客户现行情况，组合出不同的安装包。将这些安装包分发给执行安装任务的人，并通知安装组。这标志着该流程的结束，转入《产品实施流程》。主版本发布流程与补丁发布流程相比，主版本发布流程参与的职能部门个数和次数明显增多，同时设置的检查点也随之增多。其中最重要的一点是引入客户监督。采取“我们主动争取客户全程参与”的方法，每完成一个变更，不一定要待版本中的所有变更完成，立刻放上客户使用的测试环境，请客户在线试用并提意见。这样做的目的是让客户不仅知道我们在干什么，还知道我们干成什么样，以及是否满意。尽量让客户的意见在开发早期提出，越早提出，变更成本越小，且能直接减少后续的补丁发布频率。流程图如下：主版本发布流程图（下图中每个方框代表一个进程，括号内描述该进程的具体内容。每个进程均要求有物理产出。）需求人开始开发人配置管理员测试人/安装人客户提出变更请求需求人填写自己负责的《[产品名][版本号]开发计划清单/测试清单/变更清单》（以下简称清单）。如果需要，需求人可以请求召开需求澄清会。在会上，开发人、配置管理员和测试人/安装人可以就清单提出疑问或质疑，并预估所需工时。如果评审通过，需求人宣布变更计划，通知SCM检入变更计划，通知开发部经理接收任务，以及通知客户。这个过程需要在上一主版本正式对外发行前完成。检入变更计划检查是否通过澄清会。将一个产品中，各需求人提出的清单中，已通过澄清会的内容，合并成一份。从此本流程仅使用合并后的清单。将合并后的清单存入VSS的固定目录，并标上Label。通知开发部经理和测试组长。重新进入开发阶段开发部经理根据任务安排开发人，并预计开发完成时间。通知相关人，并为开发部门设置权限。测试组长按照清单，制定测试大纲和测试计划。开发人执行变更。提供发行说明内容各需求人提供自己所辖范围内的说明内容，并参照样本填写。这些步骤将重复进行，直到主版本发布完成。的安装包；2、发送安装包给客户；3、更新变更清单网页）客户反馈（1、收集客户反馈；2、分析反馈内容；3、修复问题并打补丁；4、更新变更清单网页）版本维护（1、对已发布的版本进行维护；2、修复已知问题并打补丁；3、更新变更清单网页；4、定期向项目管理组汇报维护情况）版本升级（1、根据需求和市场情况，制定升级计划；2、执行升级计划；3、更新变更清单网页；4、定期向项目管理组汇报升级情况）开发人员执行变更，定期向项目管理组汇报开发进展。收集并审核发行说明内容，产生alpha版，直至所有变更完成。安装alpha测试环境，进行部门内部测试和需求确认测试。alpha阶段的测试相当于单元测试，确认功能是否完整、是否正常运行、相关手册是否最新。如果需要，制作发行说明网页，根据收集并审核通过的内容，制作成适合客户在线阅读的网页等格式，变更清单除外。进行版本测试，根据测试计划测试，写安装手册，并进行需求确认测试，确认功能是否满足要求，尽可能提出改进意见。如果alpha阶段测试通过，进入Beta阶段测试。否则，重新进入开发阶段。在Beta阶段，需求人、开发人和配置管理员进行物理配置审核，检查各类文档是否备齐，是否全部测试通过等等，详见《CheckList》。产生Beta版，关闭VSS权限，标Label，编译构建beta版、备份、通知相关人，制作变更清单网页等等，详见《执行列表》。安装Beta测试环境，公司内部用和客户用分别进行，根据测试计划、安装手册，安装测试环境（可能有多套环境），验证安装过程是否正确。如果客户参与测试，进行验收测试，根据测试计划测试，回复测试结果（含邮件、上传VSS、书面三种方式）。进行安装记录验收测试，对产品进行测试、试用，包括性能、功能方面的测试，尽可能提出意见。如果Beta阶段测试通过，进入Release阶段，否则重新进入开发阶段。在Release阶段，进行物理配置审核，检查各类文档是否备齐，是否全部测试通过，检查变更清单网页，下一主版本计划已备妥等等，详见《CheckList》。产生Release版，标识、备份、记录，通知相关人等等，详见《版本发布前的checkList》。分发Release版，根据安装组的工作计划、根据各客户现行情况，组合出不同的安装包，发送安装包给客户，更新变更清单网页。收集客户反馈，分析反馈内容，修复问题并打补丁，更新变更清单网页。对已发布的版本进行维护，修复已知问题并打补丁，更新变更清单网页，定期向项目管理组汇报维护情况。根据需求和市场情况，制定升级计划，执行升级计划，更新变更清单网页，定期向项目管理组汇报升级情况。本文介绍了软件发布过程规范的相关内容，包括产品实施流程和VSS管理流程。在产品实施流程中，实施经理需要制定具体的实施计划，包括时间、地点、人物、实施内容和实施策略等。同时，需要分发Release版并进行前期准备工作。在执行实施计划时，需要配