Uninote
Uninote
用户根目录

迭代流程

启动阶段

  • 产品:发布需求文档(增量部分,全量部分要求在发布前更新完成)(禅道)
    • 整个迭代周期,都需要不断的更新文档
    • 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 都需要备注测试范围

tech release note

开发规范

点赞(1) 阅读(1) 举报
目录
标题