DMISO软件发布管理控制程序

1、文件发行及分发状况收文章发行章分发部门份发行部门数变更履历No.版本修订日期修订内容修订者123456789101112131415161718制作审核批准张琦1 目的软件发布阶段的主要工作是进一步稳定产品，保证生产版本的按时推出。制定良好的软件产品发布规程，并严格按照规程发布软件产品或软件版本，是保证软件产品质量和成功交付的关键过程之一。2 范围本程序适用于软件产品开发、工程应用及公共管理等部门，涉及产品、项目、架构/ 开发、测试、软件配置管理、运维与技术支持等角色或岗位。本程序关注软件产品在系统测试完成后到上线试运行或交付客户之前的工作流程，不涉及软件产品的需求、设计、开发等环节。3 定义

2、软件产品发布是在系统测试完成后，进入验收测试阶段时进行第一次安装或部署。软件发布阶段起始于Alpha 版本的推出，终于软件生产版本（RTM）的发布。在试运行阶段到验收完成期间通过适当的变更控制，根据需要可发布多个不同版本。当客户验收确认完成后，对客户进行正式发布。正式发布的内容主要包括：完整的软件系统、系统源代码、相关脚本、第三方软件产品或依赖库包等；相关的产品和工程技术文档，例如：系统设计文档、产品质量评估报告、用户手册、系统运维和技术支持文档等。4 职责角色职责决定产品发布的内容和发布日期；产品系统展示、产品交付、用户培训。制定产品发布策略，结合变更管理，和产品人员一起确定发布的确切内容和

3、发布计划；组织对发布前各软件版本进行验收评审，确保只有正确的、被授权的和经过测试的软件产品或版本才能导入实际运作环境；项目严格按照软件产品发布规程组织实施软件产品的发布工作，协调发布过程中的各项资源；发布进度跟踪和风险控制。负责创建和维护有关产品发布的各种版本，例如RC版、 RTM 版等；开发修复软件缺陷、持续完善系统；协助进行产品的安装部署，支持系统集成。执行验收测试和产品预发布测试；测试缺陷的记录、跟踪、分析和管理；提交测试报告，产品质量评估。协助产品人员和项目人员，对发布前的各种软件版本进行审核；发布基线的管理，涉及发布的配置审计；配置管理配置状态监控和报告；项目过程资产信息的整理和归档

4、。发布环境的搭建、测试和持续优化；运维 / 技术支持产品安装和部署；系统监控维护。5 程序5.1 Alpha 阶段产品 / 项目开发测试配置管理运维客户产生 alpha 版（可能会产生多个alpha版，直到所有变更和大的缺陷修复完成）1. 产品验证和体验1. 修复软件缺陷Alpha阶段1. 组织进行技术评审，项目干系人参加，针对本阶段的工作成果2. 若评审通过，则进入下一阶段；否则，修复缺陷，完善系统，重新发布 alpha 版并进行验收测试安装 alpha 测试环境1. 根据测试计划，1.协助产品 / 项目人执行验收测试，员进行版本控制包括：功能、性与基线的管理能、安全、兼容2.配置状态监控和

5、性及安装测试报告等，并提交 alpha3.验收测试报告提交变更管理和控制记录2. 缺陷的提交、跟踪和分析等1. 准备并提交 产品和运维环境规格说明书2. 为产品的 alpha 测试环境安装和部署提供协助和技术支持参加？1. 产品验证和体验2. 确认需求和功能，尽早地提出改进意见5.2 Beta 阶段产品/项目开发1. 进度跟踪和控制1. 修复软件缺陷2. 沟通协调、需求变更控制，风险Beta阶段1. 组织进行技术评审，项目干系人参加，针对本阶段的工作成果2. 若评审通过，则进入产品的预发布测试阶段；否则，修复缺陷，完善系统，重新发布 beta 版并进5.3 预发布阶段测试安装 beta 测试环

6、境1. 根据测试计划，执行验收测试，主要关注常用功能、业务价值高、复杂容易出错、性能瓶颈等所在的模块2. 缺陷的收集、整理、提交、跟踪和分析等3. 结合客户的反馈意见或客户提交的验收测试报告，生成 产品质配置管理运维1. 物理配置审核，项目过程资产信息归档2. 产生 beta 版，生成正式的外部版本号，对外发布1.协助产品 / 项目人1.为产品的 beta测员进行发布版本试环境安装和部与基线的控制和署提供协助和技管理术支持2.配置状态监控和2.准备预发布测试报告环境和产品环境3. 提交变更管理和控制记录客户1. 进行全面的有关产品功能和性能方面的验收测试2. 反馈测试过程中遇到的各种问题和缺陷

7、，尽可能提出完善和改进意见和建议3. 如果可能，提交正式规范的 beta 验收测试报告产品/项目开发测试配置管理运维客户预发布阶段1. 物理配置审核，项目过程资产信息归档2. 产生 RC 版（发布候选版） ，生成正式的外部版本号，对外发布安装预发布测试环境1.进度跟踪和控制1. 修复软件缺陷1.根据测试计划，1.协助产品 / 项目人1.为产品预发布测如果需要，在可控的2.沟通协调、需求执行预发布测员进行发布版本试环境的安装和前提下，可以尝试在试，主要是进行变更控制，风险与基线的控制和部署提供协助和正式环境中安装部署全面地查漏补RC 版并进行试用和管理技术支持缺，为正式版的2.软件配置状态监2.

8、准备产品环境体验，并反馈意见发行做最后的准控，提交 配置状备态报告2.缺陷的收集、整3.提交变更管理和理、提交、跟踪控制记录和分析等3.提交产品预发布测试报告 和更新的产品质量评估1.组织进行产品发因为测试环境和线上环境并不完全相同，即使是经过严格的测试，软件部署到线上服务器之后还是布评审，项目干系人参加，针对经常会出现各种问题。本阶段的工作成果因此，在系统上线或新功能发布时，应先发布到预发布机器上，而不是直接发布到线上服务器。2.若评审通过，则开发工程师和测试工程师在预发布服务器上进行预发布验证，执行一些典型的业务流程，确认系统进入产品的正式没有问题后才正式发布。发布阶段；否则，修复缺陷，预

9、发布服务器和线上服务器都部署在相同的物理环境，使用相同的线上配置，依赖相同的外部服完善系统，重新5.4 正式发布产品 / 项目开发测试配置管理运维客户正式发布1.系统展示、用户开发工作总结，整理培训，提交 产品并提交有关架构、系使用手册统设计和开发的工程2.项目总结，提交技术文档项目总结报告软件产品及相关资产的正式交付或分发1. 产品使用跟踪1. 修复软件缺陷根据用户和市场反馈，进行产品新版本或下一代产品的规划1. 物理配置审核，项目过程资产信息归档2. 产生 RTM 版（最终发布版） ，生成外部版本号，正式对外发布产品测试工作总结，配置审计，提交配提交产品测试总结置审计报告报告和更新的产品质

10、量评估报告缺陷的持续收集、整1.协助产品 / 项目人理、提交、跟踪和统员进行后续发布计分析等版本与基线的控制管理2.配置状态监控1. 产品环境的初始化、测试与优化2. 产品的安装、部署3. 提交系统运维和1.系统监控和维护1.软件产品的正式2.运行故障处理验收和接收3.性能持续优化2.产品的使用、问题反馈及需求变更请求5.5 软件版本号策略基于 GNU 风格的方案：主版本号. 子版本号. 修正版本号. 编译(构建 ) 版本号Major_Version_Number.Minor_Version_Number.Revision_Number.Build_Number示例：， 2.0 ，产品初版本时

11、，版本号可以为0.1 或，也可以为1.0 或；当产品进行了局部修改或缺陷修复后，主版本号和子版本号都不变，修正版本号加1；当产品在原有的基础上增加了部分功能，主版本号不变，子版本号加1，修正版本号复位为0，因而可以被省略掉；当产品进行了重大修改，或者新增功能累积较多，而导致项目整体发生全局变化时，主版本号加1；编译版本号一般是编译器或构建工具在编译或构建过程中，按一定规则自动生成的，我们只定义其格式，并不进行人为控制。5.6 发布前的版本控制此版本表示目前仅仅是一个初步完成品，通常只在开发者内部交流，或者发布给专业测试（ alpha ）版人员进行内测。一般而言，该版本软件的bug 较多，普通用户最好不要安装。（ beta ）版ZBB（ Zero Bug Build）版（ gamma ）版RC（发布候选版）Trial （试用版）该版本相对于版已有了很大的改进，消除了严重的错误，但还是存在着一些缺陷，需要经过大规模的公测来进一步消除。这一版本通常是免费发布，用户可从相关的站点下载。通过一些普通用户特别是专业爱好者的测试，将结果反馈给开发者，开发者们再进行有针对性地修改。某天的版本要把在之前（例如48 小时前）记录的Bug 都解决掉。有时也称 RC（发布候选版） ，该版本已经相当成熟了，与即将发行的正式版相差无几，如果用户实在等不及了，尽可以装上一试。Rel