敏捷开发模型文档

立项阶段

创建需求单

由业务人员确定是否需要立项，确定立项后需要在 dlm 上面创建需求单，并填写相关信息。

创建 SR

需求单确定下来后，由 QA 角色人员确定工期，然后并在 DLM 系统中创建 sr，每一个 sr 对应的是一个版本迭代的软件过程。

版本周期

一般情况是两周一个版本。

移交过程规范

通常是根据 SR 确定开发分支，根据版本周期确定 release 分支。其对应关系是，release 对应多个 sr 分支。 在每次开发移交代码时，都需要把开发分支的代码合并到 release 上去。

设计阶段

需求澄清

由业务同事发起会议邀约，与会人员包括但不限于：开发人员、测试人员、UE 或 UI 人员，会议主题包括但不限于：需求讲解、需求评估等。主要是业务同事对需求进行讲解，讲解其具体实现效果，然后由其他人员评估是否可以实现以及实现细节等。 会后由业务同事撰写会议纪要，并抄送给各与会人员，形成统一意见。

需求反讲

开发同事在需求澄清完，根据自己对整个需求的理解过程撰写概要设计文档，之后发起会议进行评审。 概要设计文档包括但不限于：业务背景、主要功能点介绍、业务规则/流程变化、数据结构/数据流变化、关联系统影响分析、日志埋点变化、定时任务变化、安全控制、测试影响面分析等。 需求反讲的作用在于评审开发人员是否完全理解需求过程，对代码实现过程起到理论先行的作用，有利于避免推倒重来的返工风险。

实现阶段

版本移交

所谓移交就是把代码部署到测试环境，然后看下代码在测试环境上的运行效果。主要指把代码转移交付到测试环境。

主要步骤：

1. 开发人员 clone 对应开发分支的代码到本地；
2. 开发人员进行开发，并完成自测、联调等；
3. 开发人员把代码提交到 gitlab 上，并发起由 “开发分支” 到 “release 分支”的合并请求；
4. 开发人员在 dlm 上创建 bug 单，并把 bug 单的状态修改为开发完成状态；
5. 开发人员发起移交邮件；
6. 版本管理员合并请求，并发出验证链接，并通知开发人员进行验证；
7. 开发人员进行验证代码是否在打的包里面；
8. 版本管理员把包发给部署人员，由部署人员进行部署；
9. 部署完成后，版本管理员会通知开发人员，开发人员去测试环境上进行验证，验证通过后，把 bug 单关闭；

Apollo 配置发布

当需要增加一些公共配置项时，可以通过发送邮件给 Apollo 管理人员，并分别配置不同环境上的值，并抄送给测试人员以便测试人员了解影响范围。

移交紧急版本

版本移交时间一般是 9am，11am，17pm，三个版本，如果由于没有开发完成或者需求比较紧急，可以走紧急版本，同样是发送邮件，并在邮件中书写好移交内容及影响的测试范围。

SQL 扫描

当开发过程中涉及到 sql，就需要在 sqm 系统中提 sql 的审核工单。这样通过 sqm 系统中设置的审核规则，对 sql 进行扫描，达到第一道防线的目的。

安全扫描

所谓安全扫描就是对后端接口进行的安全方面的评估。步骤是：

1. 由 tpm 在 sdlc 系统上面提交本次需求的安全检查点；
2. 再由开发人员在 sdlc 上面针对每一个接口书写安全检查点的具体内容；
3. 最后由 tpm 对开发人员书写的安全点的检查内容做评估，评估是否通过；

安全检查点一般分为四类：

1. 参数校验（包括但不限于非空校验、格式校验、边界值校验）
2. 权限校验（包括功能权限校验和数据权限校验）；
3. 参数化 sql

Showcase

showcase 是开发人员开发完需求后，并把代码同步到测试环境，通知测试人员、业务人员及其他需求相关人员在测试环境上进行首次演示的过程。其目的是告知各需求相关人员，需求已经基本完成，可以移交测试同事进行测试了。演示时，并不是演示所有的功能，通常的做法是测试同事根据测试案例进行挑选出几个重要的测试案例，只要求整体流程执行通过即代表 showcase 通过，不纠结细节内容。

首移

首移即首次移交给测试，需要发首移邮件通知各需求相关人员代码正式交付给测试人员。其主要目的是告知测试人员，需求已基本开发完成，可以在测试环境上进行测试及验证。

代码评审

代码评审是在首移完成前需要进行的操作，主要是由同组开发人员对本次需求的代码进行走读，通过集思广益及经验内容对代码进行检查。

主要经验：

1. controller 的接收参数是否做了参数校验（包括但不限于非空、边界值、格式、逻辑（开始日期不能晚于结束日期、金额不能小于 0 等））；
2. controller 中是否完成了功能权限校验及数据权限校验；
3. controller 中返回结果是否是通用格式（ResultUtil.succeed(object)，而不是直接返回一个 object）；
4. controller 中是否对接收的参数和返回的参数进行日志打印，以便后续出问题了查询日志；
5. 关键业务中是否对 controller 做了防重放操作；
6. service 中是否有业务处理过程的注释，尤其是枚举值的注释；
7. service 中是否对关键流程做了日志记录；
8. service 中是否对关联系统做了返回值是否为空的判断，以便防止出现空指针异常；是否对被调用的关联系统的接口容量进行判断和评估；
9. service 中是否对异常信息进行捕获，打印日志后，并输出异常信息；
10. service 中如果涉及到文件操作，是否对文件及文件流进行关闭；如果涉及到下载文件，是否对服务器本地目录中的缓存文件进行删除；
11. service 中如果需要使用到缓存，是否要对缓存执行更新；
12. service 中关键数据是否是从后端 session 中获取而非从前端传递；
13. service 中涉及到日期处理时，是否对日期作格式化操作；

单元自测

单元自测是由开发人员对自己开发的代码进行测试的过程，可以使用天狼星进行自动化生成，再 mock 数据，直到所有的代码内容都覆盖。单元测试本质上属于软件代码实现的一部分。

测试阶段

冒烟测试

所谓冒烟测试，即首移后测试人员针对测试案例挑选出来的又一部分案例，在测试环境上对软件系统进行再次粗测试的过程。

系统测试

就是按照软件测试案例，一条一条进行执行的过程，要求有截图信息，以便后期出现生产问题时进行溯源。

代码封版

系统测试完成之后，代码基本不会再进行修改时，需要对代码进行冻结，要求代码不再进行改动。

回归测试

在代码冻结后，对测试环境再次挑选重要案例进行执行的过程。其目的是再次验证冻结后的代码没有问题，为投产作准备。

投产阶段

投产代码验证

完成回归测试后，由版本管理员对代码进行打包，然后由开发同事验证打出的包中的代码是否都是自己本次版本内容修改的代码，防止夹带的发生；

通常检查内容有：

1. 投产 sql 及回滚的 sql；
2. Apollo 的配置项及配置项的值；
3. 代码内容是否都是自己修改的，公共文件有涉及其他开发同事修改的，需要找到对应的开发同事进行确认；