06.持续交付

一灰灰blog技术管理技术管理约 758 字大约 3 分钟

再团队搭建之后,我们首先面临的问题就是如何统一大家的工作模式和日常习惯。 由于每个成员的履历背景、事务认知的差异性以及既往工作经验对当前项目的适配程度高低,都将影响我们的对项目持续交付流程的制定。再正式开始之前,借助哲学的一句名言 “一切事物总是在不断发展变化之中”,因此不要妄想一蹴而就的打造一个完美的工作流程,选择一个学习成本最低且适用于当前的项目的演进,就不算是失败的决策

接下来我将以下面几块内容进行阐述

  1. 持续交付的内容拆解,基于业界理论or最佳实践模式作为输入支撑
  2. 以一线程序员视角解读交付过程
  3. 以技术管理视角接的交付过程
  4. 结合当前项目实际场景,选择适用的持续交付策略

1. 什么是持续交付

持续集成,持续交付,持续部署属于DevOps中的相关概念,我们这里引入“持续交付”来介绍如何搭建团队的工作流程

首先我们简单的解读一下这里的“持续交付”的概念

持续交付(Continuous delivery)指的是,频繁地将软件的新版本,交付给质量团队或者用户,以供评审。如果评审通过,代码就进入生产阶段。

再简单一点来说,也就是作为研发人员,从产品经理那里获取到原始需求之后,从研发开始到上线之后的回归,再这一周期内,我们应该遵循什么样的规范/规则来执行

1.1 交付流程关键节点

研发过程关键节点
研发过程关键节点

上图是一个通用的研发过程关键节点,针对这些重要的节点,抛出一些疑问事项

  1. 需求串讲
  • 即产品的需求交底过程
  • 如何进行? 目的是什么?
  1. 反串讲&技术方案评审
  • 研发理解需求之后,主导的实现思路/技术方案的串讲
  • 是否一定需要? 如何进行这个过程? 怎么评判它的执行效果
  1. 研发
  • 研发过程走什么样的开发模式, 瀑布、迭代、敏捷?
  • 研发进度如何把控,如何识别风险事项?
  1. 联调自测
  • 前后端如何联调,边开发边联调,还是约定时间专项联调?
  • 自测范围包含哪些,如何做自测?
  1. 测试上线
  • 测试用例怎么维护,如何评判上线标准?

1.2 过程规范

基于上面的过程节点,我们来看一下是否

Loading...