座舱合入申请流程指导书

源文档: https://mi.feishu.cn/wiki/XcSBwykEYi4oV1k04TCcmxpyn1c document_id: Xxmzd5m1xoWUO9xJsfWcZAs7nzh 抓取说明: 本文档位于 wiki 空间 7541461146314817537(与发版文档空间权限不同),所有图片 API 下载均 403,仅保留 feishu.cn/file/{token} 形式的原链接;3 个白板已转写为文字流程。

目的

代码管控期间,在代码合入之前,充分评估软件变更的有效性及其影响,以尽早识别风险,预防问题,确保软件版本质量。

本流程旨在通过线上流程的方式,更好的支持代码合入申请从提出到合入全周期的活动,提升有效性和效率;

实现:

  1. 多项目/团队登记入口统一, 消除多项目多车型评审冗余/ 项目依赖
  2. 验证状态的自动获取 (从gerrit)
  3. 主管确认状态的信息获取 (提出人书写)
  4. 自动检查工具/ 代码评审工具的调用,及风险获取

参考文档

适用范围

数字化主要覆盖如下范围。

  • 适用座舱所有合入管控期间的合入评审流程,包括域内& 住户;
  • 线上流程可直接在流程中进行检查项确认,即不需要额外编制代码合入检查单

流程总览白板(已转写)

来源: whiteboard Gieawx0S8hgVnPbh06QcxYUpnnb

主流程(从上到下):

活动角色(R=负责, S=知会)输入输出
必要性批准R: SRC委员会接口 / 发起方部门总经理;S: 项目组成员必要性&可行性评估结果
开发&测试R: 项目组成员正式的需求1/完成评审的代码 2/通过的测试报告
合入检查R: 项目组成员主线3天性能ok / 合入检查通过代码合入检查单
登记申请R: 项目组成员代码合入检查单 / 已登记的合入申请代码合入申请清单
预评审R: 评审委员;S: 项目组成员研发主管的合入建议
正式评审R: 团队主管;S: 项目组成员评审结论
合入分支R: 开发工程师

触发条件备注:

  1. 没赶上最后一轮集成测试的需求,触发代码合入控制流程
  2. 没有赶上 MRD 之前的最后一轮回归测试的 bugfix,触发代码合入控制流程
  3. 座舱配合发版情况,所有 bugfix 合入均触发代码合入控制流程(如 lemans 单月版本,无集测安排,不接受需求)

Workflow

流程图白板(已转写)

来源: whiteboard CtWUwggj0hl2tebJ9ktc8FQQn6g(grid 内左侧)

关键节点流转:

[合入申请] (浅蓝, 手动)
    │
    ▼
[合入前检查 a&b&c] (黄色, 工具自动)
    │  工具根据提交的申请, 去gerrit中查询, 都满足则自动通过
    ▼
[业务负责人/技术leader 确认] (浅蓝, 手动)
    │  按照申请时填写的责任人, 自动分配; 手动点击通过
    ▼
[主管确认] (浅蓝, 手动)
    │  按照登记的团队, 分配给到不同的主管; 手动点击通过
    ▼
[待评审] (浅蓝)
    │
    ├──评审通过──▶ [评审通过] (绿色, 最终态)
    ├──评审拒绝──▶ [评审拒绝] (绿色, 最终态)
    └──待定─────▶ [待定] (浅蓝)
                      │  挂起项确认
                      └──▶ [评审通过] (绿色, 最终态)

自动检查项说明(评审 d&e 在 “自动检查” 节点执行):

  • a. 验证结果确认 V+1
  • b. 主线 3 天确认
  • c. 验证人与 +v 是否一致?
  • d. 评审 skill 结果
  • e. AI code review
  • f. 代码变更量确认(>200 行)

节点配色含义:

  • 浅蓝底色:需要 owner 手动操作的节点
  • 黄色底色:工具自动操作的节点
  • 绿色底色:最终态
  • 红色边框:为显示的过程状态

流程图配图(403 不可下载)

登记申请

  1. 申请入口:https://project.f.mioffice.cn/intelligent_cabin_codemr/codemr/create?parentUrl=%2Fintelligent_cabin_codemr%2FfeatureHome%2Fnav-ILMwIHhvg
  2. 申请人填写申请的基础信息,确认创建。然后再完善表单内容,点击完成节点 (节点变绿色)

住户:软件团队选住户之后还需要选择住户名称,如果没有对应的业务,或者没有 gerrit 的权限,参考文档申请住户入住 汽车部座舱新住户申请入住说明

  1. 特别注意以下信息填写:

    1. 必要性说明: 若涉及批准,如整车评审通过,总经理批准等要求,请在追赶必要性外,附批准记录;
    2. 业务负责人/技术leader: 研发团队的小组长或者业务 SE,作为后续节点的负责人;
    3. 测试人员:请务必完整填写验证人,以避免由于 “测试人员” 与 gerrit +v 成员不一致,导致的节点阻塞
    4. 对应主线patch: 作为主线 3 天的检查依据,请正确填写主线提交记录,避免节点阻塞
      1. 不足三天,需要追赶的,可以点击申请特批,申请之后将由软件团队主管进行批准
    5. Patch url: 作为后续自动检查是否完成合入的关键输入,请确保链接准确;

合入前检查 - 自动

  • 系统自动检查,以下全部通过,节点自动完成;申请人关注节点状态,及时推进;
    1. 验证结果确认 V+1?
    2. 主线 3 天确认?
    3. 测试人员与 +v 一致?
  • 验证相关的不一致,申请人及时联系测试人员进行纠偏/偏差;
  • 主线不满 3 天,申请人及时提出偏差申请,并联系主管批准;

业务负责人/技术leader 确认

团队 leaders 就变更的必要性,方案有效性&合理性,代码实现与设计的一致性进行检查确认,无误后完成节点。

主管确认

主管就变更的必要性,方案有效性&合理性,代码实现与设计的一致性进行批准确认,无误后完成节点。

自动检查- 自动

系统自动就编码规范&修改的合理性进行 ai 检查,给出评审建议。

Xx 车型评审- (评审会议)

QA 组织会议,会议根据申请的必要性,方案有效性&合理性,代码实现,验证结果,风险等进行决策,给出评审建议:

  • 评审通过: 评审流程结束,QA 标记 TR 版本,完成评审节点
  • 评审拒绝:评审流程结束,QA 标记 TR 版本为 NA,完成评审节点
  • 评审待定:QA 标记 TR 版本为待定,完成评审节点,指派任务,进入待定节点;

Xx 车型待定 & 待定验收

  1. 待定:任务责任人完成任务后,完成节点
  2. 待定验收:QA 对待定任务完成情况进行确认,并据此给出最终意见
    • 评审通过: 评审流程结束,QA 标记 TR 版本,完成评审节点
    • 评审拒绝:评审流程结束,QA 标记 TR 版本为 NA,完成评审节点

申请总经理特批

管控期间(Last 轮集测启动之后)原则上不接受需求合入;

到达 xxx 车型评审节点后,系统将自动判断合入类型,若为需求,系统将

  1. 自动将评审结论置为拒绝;
  2. 发信息给到合入申请创建人,确认是否需要发起总经理特批;
    1. 若选择不发起,流程结束,拒绝合入
    2. 若选择发起,系统将自动拉群,由申请人补充追赶必要性 & 方案合理性等,并最终由总经理发起决策;
    3. 注:相关群暂不拉座舱外成员;

快捷查询

我的工作台

进入 我的工作台,可以快捷查询车型管控策略 & 评审计划 & 个人待办 & 新建申请

此页面仅合入信息,不包括住户准入准出信息

  • 我的待办: 我未完成被分配节点的合入申请;
  • 我的关注:我相关的合入申请,如我是测试人员,合入前检查,没通过的申请;
  • 新建: 创建合入申请

合入申请总览

进入 合入申请总览,可以快捷查询车型/团队/版本 相关合入详情

总览看板白板(已转写)

来源: whiteboard CcArwg5OChZCI7b2phnc7RarnTc

条件筛选区:可根据实际需要对 合入车型 / 软件版本 / 软件团队 进行筛选。

看板显示区(4 个卡片):

卡片数据范围关注角色
合入申请 by 状态按筛选条件展示 申请状态;待评审状态=合入评审会议准入状态;饼图,单击对应区域可查看清单业务负责人关注(业务负责人/技术 leader 确认状态);主管关注(主管确认状态);QA 关注(待评审状态)
存在风险的合入申请按筛选条件展示 未完成评审条目 ai 风险;评审会议参考意见;单击对应区域可查看清单业务负责人 & 主管(评审会议前可关注信息)
合入数量 by TR按筛选条件展示 评审结论;TR1-TR4=评审通过的合入申请;NA=评审拒绝;空=未评审;单击对应区域可查看清单TPM & 测试业务线(回归范围)
合入申请 by 版本按筛选条件展示 申请数量;单击对应区域可查看清单all

问题反馈


变更历史

版本变更历史变更时间
V1.0初始发布2026/04/15
V1.14.8 章节:新增 “申请总经理特批” 节点2026/06/02