一、发版流程

1. 需求收集：产品经理与客户或其他相关团队（如云数中心、云网产品）沟通，了解需求和期望（产品经理）
2. 需求分析：调研各项需求并输出PRD（产品需求文档）（产品经理）
3. 需求评审：产品方案评审，同时明确功能是否继续，进行确定前后端、测试人力及排期（前后端、测试、产品经理、技术经理）（产品经理）
4. 视觉评审：明确排期的功能，由产品经理协调进行视觉设计，输出交互示意图
   
   🔗主要责任人：产品经理
    交付：产品需求文档PRD、功能排期至那个版本、交互图
   
   
5. 功能设计：基于PRD，研发团队进行系统设计，包括架构设计、数据库设计、接口设计等。设计结果会被记录在设计文档中，完成后进行小组内部技术评审，时间自行决定。（后端开发）
6. 功能评审：基于小组内通过的技术方案设计，面向前后端+测试+产品进行功能评审会，再次明确细粒度的排期，并反馈给产品、测试提测时间。（后端开发）
7. 开发：研发团队基于设计文档开始开发工作。同时，产品团队和开发团队需要紧密配合，以处理在开发过程中出现的任何需求变动。（前、后端开发）
8. 自测：基于测试用例完成功能自测、前后端联调、自测文档（基于测试用例）撰写，完成后拉产品校验自测结果，通过校验后提测。（前、后端开发）
   
   🔗主要责任人：前后端开发人员
   交付：技术方案设计、接口文档、细粒度排期、前后端自测文档
   
   
9. 测试：开发完成后，交由测试团队进行测试，以确保系统的质量满足预定标准。测试团队通常会编写测试计划和测试用例，然后进行系统测试、集成测试、性能测试等。测试结果会被记录在测试报告中。（测试）
10. 灰度测试：测试完成后，首先在一部分用户或一部分环境中进行部署，这就是所谓的灰度测试。在灰度测试中，运维团队和测试团队需要密切协作，监控系统的运行状况，并进行必要的调整。（测试）
    
    🔗 主要责任人：测试
     交付：测试用例、bug单、一轮二轮测试报告
    
    
11. 上线：灰度测试成功后，系统将被部署到全部的用户或环境中，即正式上线。在这个阶段，运维团队需要准备好应对可能出现的各种问题，包括系统崩溃、性能下降等。（前后端各自升级部署）
12. 后续维护：上线后，运维团队需要持续监控系统的运行状况，并及时进行必要的维护和升级。同时，产品团队需要收集用户反馈，并据此提出新的需求，进而启动新一轮的开发、测试和上线过程。（前后端值班）--问题记录手册

        🔗 主要责任人：技术经理
          交付：部署升级

13. 版本排期：产品经理完成需求分析后，根据给出排期时间对某功能进行版本排期规划。
14. 版本管理：根据版本上线时间给出功能从产品设计到提测、完成测试的排期（与产品经理、技术经理确认）。
15. 版本发版：输出版本报告（重要新功能给使用手册）

       🔗 主要责任人：版本经理 交付：版本跟进表、版本管理表、版本报告

二、发版计划

每三个月/大版本---发版全部资源池---新功能

每月/小版本---发版各别/全部资源池---优化及bug

三、版本号规则

主版本号.次版本号.从版本号.构建版本号

• 主版本号：当系统出现整体架构变化、大调整等场景时，变更主版本号。
• 次版本号：新业务功能开发时，变更次版本号。
• 从版本号：当前次版本进行故障修复时，变更从版本号（可能出现多个次版本同时升级从版本的情况）。
• 构建版本号：每次CI构建时，非正式发布版本，附加构建版本号。
• 示例：

四、发版问题

1. 前后端进行功能设计、前后端开发、提测过程中，①当遇技术问题、bug等应及时和技术经理沟通和同步；②当遇延期风险问题应及时和产品经理沟通和同步，如：需求变更、开发人力不足、开发时长重新评估、开发环境、测试环境受阻等一系列可能造成产品功能无法开发的问题，严重影响开发进度时，需再上升问题至组长。
2. 经技术经理与产品经理、前后端开发人员确认后，已明确无法按期开发的功能，需在封板前告知风险至版本经理，是否考虑延期或取消功能。一般情况，如因测试团队或开发团队测试、开发需短期时间延长的功能，版本可视情况延期封板和发布1-5天，如因风险过大，则排期至下个版本。
3. 及时更新进展+反馈问题，避免造成延期风险。