Complex Stable Business Development Process

没有适合所有业务的开发流程，从0开做加法，而不是从100开始做减法

对于复杂业务，模块众多，研发及测试需要跨模块开发及测试，不同模块间流程不统一导致了跨模块开发时成本的增加。因此，需要建设统一的的开发测试上线流程。此外，为了降低流程的成本，通过服务号及机器人等方式，在关键节点通过自动化手段辅助，实现无人介入的目标

阶段	阶段说明	主要角色
准备阶段	申请各种权限，为开发做准备	开发RD、测试QA
需求阶段	PM、RD及QA共同确认需求及设计，并报备需求到QA	开发RD、测试QA
开发阶段	RD开始开发代码，完成CR及LB测试	开发RD、模块Owner
测试阶段	QA完成项目测试，或自主测试报告确认	测试QA
合入阶段	代码测试通过，合入至主干	开发RD、测试Owner
预上线阶段	拉分支，进行上线前检查	开发RD、测试Owner、测试QA
上线阶段	发单上线	开发RD

人员：

• 开发RD：需求的实际开发人员，负责代码的开发、自测及上线
• 模块Owner：被开发模块的研发负责人，负责模块重点需求的方案审核，代码Review等
• 测试QA：需求的测试QA，与研发RD共同为同一需求负责，负责需求的测试、自测或测试结果的确认等
• 测试Owner：被开发模块的测试负责人，负责CI流程管理、流水线的值周工作
• 中台QA：负责模块流水线的建设，流水线非模块自身及代码问题的追查及处理等

工具：

需求阶段

需求评审

重点变更需要发起需求及设计评审，QA需介入需求及设计评审，了解项目需求及设计，并预估测试周期，给出测试排期

备注：重点变更： 1 多团队联合项目开发；2 多模块开发；3 单模块开发的重点项目；

• PM提出需求后，需发出需求邮件，并组织会议进行评审，会议参与人员 PM、RD/FE、QA，综合评审意见后发布需求文档

• 需求变更时，PM需要发出需求变更邮件，并与各角色确认

• RD设计完成后，需要组织会议进行设计评审，会议参与人员RD/FE、QA，非模块负责方的第三方需要邀请模块负责方参加评审，最终产出设计文档

建立卡片

需求及设计明确后，RD需要在项目管理空间建立卡片，不可复用已经上线的卡片（卡片类型包括软件工程中用户故事地图的史诗级故事Epic、需求Story和任务Task等等）。

RD填写卡片对应字段，包括不限于负责人、所属计划、优先级、RD负责人、开发团队、开or关开关、是否免测、小流量类型、背景需求、方案概述、预期收益、修改点、影响面、设计文档（没有写『无』）等

对于可自主测试需求，卡片类型为免测，自主测试不再强制要求免测标准，以流水线是否能够覆盖需求风险来判断。

研发同学如无法判断需求是否可自主测试，可与业务负责QA共同确认

需求报备

研发建立需求卡片后，可通过机器人在群里进行需求报备，需求报备主要用于QA提前分配项目人力，因此对于需要QA测试的项目，尽量提前报备，对于自主测试项目可天级随时报备，不报备的项目将无法CI及上线。研发报备后，QA需在每周一、周三进行项目排期及分配人力。

开发阶段

1. git stash; git pull --rebase origin master; git stash pop （先把本地变更保存一下再pull）

2. 编写代码

3. git add 修改文件（慎重使用git add .）

4. git commit -m "STORY卡片编号" （没有story id不予CR）（如果成功，本地master领先于origin/master）

5. git push origin master:<cr分支>（用于将本地 master 分支更改推送到远程代码审查的环境，而不是直接推送到远程的 master 分支，因此origin/master不变，依旧落后于master）

6. 代码评审中，RD owner +2分，对口QA +1分，组内高工 +1分，否则无法CI

7. 如果要修改，使用git commit --amend，避免一个功能在本地生成多个commits

8. 评审通过，不过本次代码还未合入代码仓库

研发发送CR后会自动触发change流水线执行，自动执行编译任务，分支开发需触发对应分支的change流水线，如需执行Local Build测试，人工点击测试阶段，触发LB任务执行。

CR完成及LB测试任务通过后，可进行提测。使用的时候需要关联卡片，创建提测单。免测项目记得选上免测。如果已经测试过了，但是合入主干前，需要up代码后重新跑lb时又到了提测阶段，可以通过选择yes，跳过提测结果

单模块研发LB自测

push 代码后，LB平台会自动触发编译，报告自查

状态	具体原因	说明	关注人员
红	流水线异常代码问题(出core、拒绝、无法启动等）	2大类：环境任务失败、测试任务失败，细分环境部署失败、工具异常、基线过老、拒绝过多、出core	研发 + 测试qa + 值周qa
黄	存在diff新增wf日志	就是测试任务失败，主要是2大类：新增wf日志、 存在diff	研发 + 测试qa
绿	基本无风险，但仍需要确认报告		研发 + 测试qa

• 基线过老：开发代码基于的base版本太旧了，云端对未发布的版本(即合入master的版本)的编译产出只保留有限的天数
• 出core：指的是程序在运行过程中遇到了无法处理的错误或异常，导致程序崩溃，并在系统内存中生成一个名为Core Dump（核心转储）的文件。这个Core Dump文件包含了程序崩溃时的内存信息和程序的运行状态，对于开发者来说，可以加载Core Dump文件和对应的可执行文件，进行调试分析
• wf日志信息： 即代码中通过warning日志
  • 基线 & 新版本均有且数量一致：找值周生
  • 基线 & 新版本均有且数量不一致：研发自行排查
  • 仅新版本存在：研发自行排查，如确定wf日志符合预期，找值周生加白名单

自测完成下述流程+LB后，研发携带卡片与项目qa沟通

多模块变更

变更可能影响交互模块性能和功能的（例如扩大召回、增加正排计算、增加远程词典访问等)

• 务必报备相关模块同学知晓（可咨询各模块值周、owner、对口QA等）
• 测试阶段需确认含网络交互时间的指标是否发生变化，提供速度小流量结论，用于评审系统延时整体变化情况
• 稳定性评审：延时退化、CPU消耗、带宽增长、内存增长等

发起提测

• 在流水线的最后一个阶段，点击”提测”
• 选择自己的story，创建提测单，填写内容，发送邮件
• 后面更改测试状态都在这里。包括打回提测、提交测试报告等
• 每次修改都要重新提测；
  1. qa修改测试状态为修复bug或者打回
  2. rd重新点击【执行】进行提测
  3. qa修改状态为【测试中】
  4. 直到测试完成

测试阶段

自主测试确认

针对自主测试需求，需求对应QA需检查代码修改是否符合自主测试要求，对于流水线无法覆盖的需求，可打回要求RD提测

对于可自主测试需求，当前QA需检查LB测试结果符合预期，模块是否自主测试通过未来期望通过智能化手段自动判断，节省QA判断人力

对于可自主测试，且LB通过的需求，QA在提测平台操作免测通过

需求测试

对于已报备且无法自主测试需求，QA在报备后及时分配测试人力，研发按照约定时间进行提测

1. 开始测试，QA需在提测平台修改状态为开始测试
2. 测试过程中发现的bug记录至线下bug空间，对于基础功能不满足需求可进行测试打回。
3. 测试完成后，QA在提测平台操作需求测试通过，并填写测试结论，通过RD准备合入。

合入阶段

前提：

• CR ：RD owner +2分，对口QA +1分，组内高工 +1分

• LB流水线执行通过

• 提测平台测试通过

满足前提后，在群里CI排队。这是为了保证合入代码有序， 出问题时可快速回溯；因此，RD同学不允许还没在群中排队， 就自行在代码管理平台上点击『合入』

具体操作是在群中，通过机器人提供的排队指令进行排队，命令包括申请排队，查看现在排队情况。

在排队队列的第一位时，请不要着急点击『合入』按钮，还需要更新最新代码：

1. git status：查看状态，发现有冲突

2. git pull --rebase

3. git log：查看当前workspace是否有自己的两个commit-id，若有(之前push了一次+git pull产生的一次)，合并到仅有一个commit-id

4. git commit --amend：在当前commit-id上继续操作

5. git push origin master:<cr分支>

6. 等待 change流水线 结束，如果change流水线执行通过， 点击『合入』

注意：

• 分支开发模块需先将代码合入分支，再将分支合入主干

• 所有要上线的story要在上线拉分支时间点（一般8点之前，具体以各部门为准）完成合入

• 当story超过5个或者当天上线风险较大时，值班qa可以禁止继续合入story

• 合入时关联的Issue号必须与提测时候的完全一致，若发现合入时的CR与提测时不符的情况，QA直接进行回滚代码

• 代码合入主干后会触发主干流水线的执行，研发及对应业务QA需关注主干流水线任务执行结果，流水线报错，流水线值周需高优解决

预上线阶段

背景知识：拉分支不等于上线，拉分支是在代码上拉了一条分支， 并且会触发分支流水线，上线是分支流水线环节中的一个任务， 发单成功后， 会看到上线单链接

拉分支会定时进行，也可以手动触发

• 定时拉分支的场景主要用于：晚上拉分支（一般是晚上8点）、部署沙盒，观察一晚上， 第二天上线
• 如果有特殊情况，可以使用拉分支指令，自行拉分支
  • 希望 下午3点拉分支， 然后 7点前上线
  • 紧急上线：工作日超过晚上7点（不是拉分支时间，是上线时间； 通过完成拉分支需要 30分钟 ~ 60分钟）或者节假日，属于紧急上线，例如希望 晚上9点拉分支， 然后 上线，值周OP同意后发，发邮件给3方经理报备：RD 经理、OP经理、 测试QA 经理

拉分支后需触发线下se部署，线下se部署完成后，自动化检查线下se状态

上线阶段

发单上线

1. 关注持续集成群内机器人发送的上线通知，会@ 到具体研发，上线owner同学按照提示组织相关同学拉群发起上线操作
2. 到 测试环境进行效果确认，以及让本次也一并上线的story的RD确认效果
3. 确认OK之后， 即可在上线系统中发单上线
4. 开始上线后，按照 各模块上线checklist 进行检查，检查上线的功能点是否符合预期。上线过程中所有参与上线的RD都必须在线check功能，全部check完成才能进行下一级
5. 上线过程中，RB的RD-owner、QA-owner负责推动上线，相关RD需积极响应上线各level的效果检查，相关QA同步检查
6. 上线完成后，上线RD发送上线通报邮件至模块对应邮件组或上线群

线上问题处理

上线过程或上线后，出现问题需要回滚时，由上线RD直接负责回滚操作，上线RD组织所有参与上线的RD开始对线上问题进行追查，需要架构RD协助的，发送邮件给架构RD。线上重大问题，架构RD也需立即展开追查。值班qa配合做线下问题浮现。

确认原因以后，无问题的story高优安排上线，有问题story重新排队上线

回滚相关：

• 上线过程中，出现零星core时，需要明确是否由上线引起：如果是上线导致，需要明确风险是否可控，并给出相关证据、结论，否则给予回滚；如果不是上线版本引起，需要找到对应版本负责人，同样明确风险，否则给予回滚。零星core认领的同时，进行core登记，并定期通报进度。
• 大规模core时、出现大量拒绝时、出现恶劣效果影响，直接回滚版本，并给出相关修复预期。
• 回滚需要通知相关上线RD，OP、QA，防止后续RD做小流量对线上版本依赖导致的问题。

紧急上线流程

• 紧急上线的代码需要1位同组高工doublecheck，qa确认流水线各项指标（diff字段变化，diff率，miss率，耗时，cpu，mem，wf日志，cache命中率等）符合预期后才能上线。
• 紧急修复代码上线前需准确判断线上问题的严重程度&影响范围，然后判定是否需要走紧急上线。
• 如果RD&QA无法判断diff报告中的某些字段变化或diff率是否符合预期，需要找相关业务各方共同check测试报告结果和上线cr。
• 如果遇到流水线异常，跳过流水线前需要拉本次相关业务同学确认本次cr是否符合预期，上线过程中RD&QA需密切关注相关监控（稳定性，各业务线效果case，展现监控等），如果遇到异常报警，需要拉相关业务负责人一起check，防止问题扩散。第二天QA要及时修复流水线，并重新验证流水线任务是否符合预期，如果有问题，及时通知RD回滚。
• 修复代码上线后，需明确线上监控指标，持续观察业务指标是否恢复，并关注其他业务线是否有相关报警，防止修复代码引入二次问题。fj观察以及全流量后，上线群里同步线上监控观察结论并确认以及留存
• 对于紧急止损的上线方案，在提测时需要明确临时方案的下线时间节点，RD和QA需共同确认保证临时方案及时下线。