06.持续交付

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

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

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

1. 什么是持续交付

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

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

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

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

1.1 交付流程关键节点

研发过程关键节点

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

1. 需求串讲

• 即产品的需求交底过程
• 如何进行？ 目的是什么？

2. 反串讲&技术方案评审

• 研发理解需求之后，主导的实现思路/技术方案的串讲
• 是否一定需要？ 如何进行这个过程？ 怎么评判它的执行效果

3. 研发

• 研发过程走什么样的开发模式， 瀑布、迭代、敏捷？
• 研发进度如何把控，如何识别风险事项？

4. 联调自测

• 前后端如何联调，边开发边联调，还是约定时间专项联调？
• 自测范围包含哪些，如何做自测?

5. 测试上线

• 测试用例怎么维护，如何评判上线标准？

1.2 过程规范

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