06.持续交付
约 758 字大约 3 分钟
再团队搭建之后,我们首先面临的问题就是如何统一大家的工作模式和日常习惯。 由于每个成员的履历背景、事务认知的差异性以及既往工作经验对当前项目的适配程度高低,都将影响我们的对项目持续交付流程的制定。再正式开始之前,借助哲学的一句名言 “一切事物总是在不断发展变化之中”,因此不要妄想一蹴而就的打造一个完美的工作流程,选择一个学习成本最低且适用于当前的项目的演进,就不算是失败的决策
接下来我将以下面几块内容进行阐述
- 持续交付的内容拆解,基于业界理论or最佳实践模式作为输入支撑
- 以一线程序员视角解读交付过程
- 以技术管理视角接的交付过程
- 结合当前项目实际场景,选择适用的持续交付策略
1. 什么是持续交付
持续集成,持续交付,持续部署属于DevOps中的相关概念,我们这里引入“持续交付”来介绍如何搭建团队的工作流程
首先我们简单的解读一下这里的“持续交付”的概念
持续交付(Continuous delivery)指的是,频繁地将软件的新版本,交付给质量团队或者用户,以供评审。如果评审通过,代码就进入生产阶段。
再简单一点来说,也就是作为研发人员,从产品经理那里获取到原始需求之后,从研发开始到上线之后的回归,再这一周期内,我们应该遵循什么样的规范/规则来执行
1.1 交付流程关键节点
上图是一个通用的研发过程关键节点,针对这些重要的节点,抛出一些疑问事项
- 需求串讲
- 即产品的需求交底过程
- 如何进行? 目的是什么?
- 反串讲&技术方案评审
- 研发理解需求之后,主导的实现思路/技术方案的串讲
- 是否一定需要? 如何进行这个过程? 怎么评判它的执行效果
- 研发
- 研发过程走什么样的开发模式, 瀑布、迭代、敏捷?
- 研发进度如何把控,如何识别风险事项?
- 联调自测
- 前后端如何联调,边开发边联调,还是约定时间专项联调?
- 自测范围包含哪些,如何做自测?
- 测试上线
- 测试用例怎么维护,如何评判上线标准?
1.2 过程规范
基于上面的过程节点,我们来看一下是否
Loading...