迭代流程

启动阶段

• 产品：发布需求文档（增量部分，全量部分要求在发布前更新完成）（禅道）
  • 整个迭代周期，都需要不断的更新文档
  • app的cms配置要有对应的文档
• all：需求评审
• 全公司相关部门：需求评审 all--
  • 确定后打印出来，各部门签字 all--
• 开发：任务分解（要关联需求），细节评估，制定技术方案，工期预估（禅道）-- 根据需求改动量相应调整评估时间，评估的细节记录文档中
• 测试：编写测试用例（初步）
• all：汇总，确定迭代内容（功能 + 必须要的 bugfix，bugfix、优化不单独安排时间，穿插在项目迭代中，任务估时时可适当考虑）、上线日期，由产品最终整理出相应文档，并发送邮件给相关人员确认
• 产品：如果有变化，周知全公司

开发阶段

• 测试：20%时间内完成测试用例（关联 任务 或者 需求）（禅道），并组织用例评审
• 测试：挑选冒烟用例
• 测试：根据接口文档编写接口自动化测试（测试用例自动化）
• 开发：每个 commit 关联 任务 or bug，任务完成时记录工时
• 开发：完成后自测（相关功能的测试用例要全部自测??），自动化测试、通过后提测
  • 提测后的bug会作为考核依据
  • 同时申请 review，合并代码

测试阶段

• 测试：执行测试用例、自动化测试
• bug 原则上要从用例转过来，没有的话新建
• 测试：完成后编写、提交测试报告
• 测试：保存完整的测试环境
  • 大功能模块测试开始、完成时分别保存一次 docker image，并且通知部门其他人员暂停更新测试环境
    • 禅道也要保存 docker iamge
  • 完整的测试环境参照
• 必须在测试环境测试

内测阶段

• 大改动发布前，需要通知其他部门内测。TODO: 内测说明模板链接
  • 不需要特别稳定的版本，尽量早的给出内测版本，以便其他部门：
    • 能够直观的再次确认需求
    • 提前熟悉新的系统，准备必要的数据、配置
• 设计：UI还原度检查
• 运维 + 测试：全新发布测试，除特殊情况外，发布必须全部自动化
  • 运维不断重复：镜像 - 自动发布 - 自测，完成后提测
• 运维 + 测试：预发测试。全新部署后将线上数据导入（改为通过镜像 fork 线上系统，再导入 pre 配置），由测试通知其他部门相关人员进行测试。
  • 测试：将相关的文档（产品需求文档、说明文档、bug）汇总给出来，便于他们测试
  • 运维：进行发布演练，整合发布文档

pre 阶段

• 测试：负责管理员账号，不要公开，相应的人分配相应的权限进行测试
• 产品：根据测试报告验收（根据功能是否符合预期、未完成的功能、现有bug决定是否发布）
• 产品：文档 tag，原型导出，这些要和正式发布的版本对应。
• 开发：检查发布的 commit range
  • 用以下命令（根据实际情况修改）生成，并复制到文档

# git log --oneline --graph <last-release-commit>..<this-release-commit>
$ git log --oneline --graph aeefd5668..c1154c2
* c1154c2 (HEAD, tag: r2020-7-22) 任务#dajx_788开发完成：优化个推配置，目标是使各端配置统一

• 开发：准备发布文档（tag/commits，sql（包含权限配置基础数据等），配置修改等）

• 开发：release note：其他部门在上线后需要做的事情。

• 产品：发布申请，批准后安排上线时间

  • 如果安排在晚上发布，评估是否需其他部门人员配合

• 测试+产品：调整禅道任务+bug（要在发布给全公司前完成）

• 产品：编写 release note，并通知公司全体同事

• 测试：编写 tech release note

• app：iOS发布提审；并发布到蒲公英内测，注意备注清晰（环境、内部版本号（带 commit hash））

• app：加固，并上传网盘(/home/pan/data/apks/online)，并按规则重命名

发布确认（运营测试）阶段

• 一般安排1-2天，同步线上数据
• 运营人员必须按照实际的运营方案来进行相应的配置和测试，即要把相同的工作在测试环境提前做一遍
• 此阶段等同于正式发布，而不能作为测试-改bug的环境，一旦发现bug、不符合需求等问题，等同于线上故障，相应人员负相应责任
• 没有严重问题，就发布上线；发现的问题后续发补丁解决

好处：

• 提高线上的稳定性
• 运营人员提前了解系统，避免上线后花很长的时间去配置 坏处：
• 增加了运营的工作量
• 发布时间对应延后1-2天

正式发布1：后台

• 运维：根据发布文档发布API、cms
  • 严格按照发布文档发布，所有未知的问题都要在测试环境先进行演练、测试
  • 找开发在一旁协助审查
  • 运行以下命令，检查更新是否成功；
  • 将输出复制到最终的发布报告中

[root@dajx-online dajx-staff-api]# git status ; git log -1
# On branch master
nothing to commit (working directory clean)
commit c1154c2c5454951fa9f429ce68e22daead56388f
Author: hcg <532508307@qq.com>
Date:   Fri Jul 10 14:47:48 2020 +0800

    任务#dajx_788开发完成：优化个推配置，目标是使各端配置统一

• 测试：兼容性测试、冒烟测试
• 测试：跨部门组织相关人员进行测试（冒烟 + 新增部分功能）
  • 测试完成后要负责清理测试数据

正式发布2：app

• 运维: 确定后台更新成功后，更新安卓安装包；并修改对应的配置
  • 安卓安装包同时发送运营人员更新应用内市场
• app：确定后台更新成功后，appstore 发布
• 商城后台要单独打包、更新
• 测试：更新、强制更新测试

后发布阶段

• 测试：镜像线上环境进行全量测试（因为发布时间很紧，延迟到发布后的测试）
• 确认全部资源已经归档，源码推送到仓库中

紧急发布流程

• 产品：立项，建立对应迭代，周知团队成员
• 开发：及时处理问题，最高优先级
  • 直接在 release 分支修复
• all：从开发到发布阶段的事情，根据实际情况来做（可以省略一部分）
• 开发：每一个任务、bug 都需要备注测试范围