Skip to content
Permalink
Branch: master
Find file Copy path
Find file Copy path
Fetching contributors…
Cannot retrieve contributors at this time
51 lines (42 sloc) 2.9 KB

开发流程

Hot Fix 流程

需求分析及确认

  1. 列出这次hot fix会影响的所有功能找个地方记下来

开发及自测

  1. 根据列出来的功能,逐一求改修改然后在本地测试

代码审查(略)

联调测试(测试环境和生产环境都做一遍)

  1. 根据列出来的功能,测试其所在的流程,在测试环境上测试然后发布生产环境测试

新需求及大范围升级修改流程

需求分析及确认

  1. 需求分析---将本次需要交付的需求点列出来并同步给每个人,大家对需求进行理解和准备,需要每个人输出:

    • 本次需求涉及到要修改的系统
    • 需求不明确的地方(必选,没有不需要确认就明白的需求)
  2. 需求确认---组织会议(或gitlab或邮件),汇总大家对需求的理解和问题,明确所有需求并列出确认后的需求点,会后需要输出:

    • 对应交付结果的每一项需求点(明确后的)
    • 行动计划,主要是会上无法确认的问题,会下必须确认
  3. 需求分解---将需求按系统分解并分配到每个人,输出:

    • 每个人明确自己负责系统的开发任务

开发及自测

  1. 任务分解---每个人根据确认后的需求做【开发任务分解】,并将分解后的任务保存在gitlab的Milestone里。如果开发中发现仍有隐藏需求,及时补充。最终gitlab上需要能看到:
    • 每个project的开发任务(后面测试也可以用到)
    • 新增的开源库(python,php。如果不写,测试环境上的痛苦到生产还得重新来过)
    • 数据库的修改(主要的影响是testApi环境的数据库不能及时同步更新)
  2. 任务计划--每个人自己对自己的任务做项目计划,输出:
    • 任务起始时间(通常都是分解完任务之后)
    • 任务结束时间(最晚的时间决定了发布的时间,如果发布的时间是定死的,这两个时间决定了每天工作的时长)
    • 前置任务(做这个事儿之前必须有什么功能先完成)
    • 后置任务(如果我这个事儿做不完什么功能就无法进行)
  3. 任务执行--开干,输出代码
  4. 任务自测--自测的准则就是对着gitlab上对开发任务的记录逐一进行功能测试,一个都不能少,并且是在测试环境上测试不是本地,输出:
    • checklist(对应gitlab的任务记录)

代码审查

  1. 和钱有关的代码需要发起代码评审,开发的人主动找人评审

联调测试(测试环境和生产环境都做一遍)

  1. 根据gitlab上面的记录发布到测试(或生产)环境
  2. 确认用户能用到的所有流程
  3. 走完在2中确认的流程
  4. 总结在2中确认的流程,整理成checklist,下一次也这么测

总结

  1. 一个交付周期遇见的问题,需要及时记录在gitlab上,否则下次会忘记。
  2. 复杂的流程需要在发布完(或者开发前)整理文档,否则早晚会忘。
You can’t perform that action at this time.