从需求到上线 | 青训营笔记

---

前言

转眼青训营也快结束，5月还真是忙…。对于青训营的学习来讲，不管课程到底教了什么，形成自己的知识体系是最重要的。

---

一、团队规模和流程的关系

为什么需要流程?
随着团队规模和问题复杂度的上升，一个人搞定一切就不可能了，超过了一个人，就需要进行团队协作，自然也就需要有流程。
常见的协作流程：

1.1、瀑布模型

瀑布模型所做的事：

• 按照时间节点参与会议，产出文档（系统分析，概要设计，详细设计，接口文档，提测文档等）

• 按照时间节点交付测试

• 按照时间节点发布

当然这种模型也有很大的缺点： 所有的工作都是按部就班的都得按前面的流程完成后面的流程。也因此瀑布模型现在用到的是，比较从传统的项目开发，又或者是上线流程非常严格的。

1.2、敏捷开发

因为这种过于重视流程的方法，无法很灵活的应对市场。敏捷开发的思想应运而生。

敏捷开发所做的事：

• 跟随迭代制定规划，进行开发

• 参与待办事项整理会议（Backlog Grooming Meeting）

  • PO描述下个迭代希望实现的用户故事

• 迭代计划会议（Sprint Planning Meeting）

  • 选择迭代的任务和估算工作量

• 每日站会（Standup Meeting）

  • 昨天你做了什么?
  • 今天你将要做什么?
  • 你有需要帮助的地方吗?

• 评审会（Retrospective Meeting）

  • 小组向产品负责人展示迭代工作结果

• 反思会（Retrospective Meeting）

• 在每个迭代后召开简短的反思会，总结哪些事情做得好，哪些事情做得不好

敏捷开发简单来说就是以更小的团队，更快速的进行迭代。因为团队小，所以大家可以围绕着一个很具体的目标开展工作，大家的合作也更加紧密在敏捷开发的概念体系里，有很多具体的方法，比如: scrum， kanban等等。scrum这个词的来源，就是橄榄球中的争球大家肩并肩，共同围绕着—个目标前进。

对于两个敏捷团队实际的流程可能如下所示：

名词解释：RD:研发 | PM:产品经理 | PRD:需求文档 | UED:用户体验设计
QA:测试 | Scrum1:敏捷团队1 | PO/P1:优先级0/优先级1 | Backlog:规划列表

二、需求流程

在这个流程阶段我们应该考虑以下几点：

• 不要浪费时间讨论不应该存在的问题
• 站在用户的角度思考
• 给出后端系统视角的建议，估算任务优先级

2.1、需求评估-四象限法

当你很多任务的时候，可以按照这个坐标，把他们按照重要性和紧急程度分类
有些事情既重要又紧急，那么我们就应该先去做，不重要又不紧急的可以最后做
而有些事情虽然重要但是不紧急他们的优先级应该比那些紧急但是不重要的事情高加粗样式，因为如果我们不去处理，后面他们就会变得又重要又紧急。

• 这个理论的原则是先判断事情的重要性，再判断紧急程度。
  一个高效的占比，应该是大多数时间在处理重要而不紧急的事情，因为一旦一件事情变成了紧急，那我们就容易犯错误，因此如果每天大部分时间都在处理重要且紧急的事情，那么其实是不健康的。

2.2、需求评估-MVP(最小化可行产品)思想

MVP(minimum viable product ,最小化可行产品)要求：

• 站在用户的角度思考
• 收集用户反馈，快速迭代

如果我们要给用户造一辆车，我们不应该第一天给他一个轮子，第二天给两个轮子，第三天给他一个底盘，第四天才让他开上车。
我们应该先给用户一个简单能用的产品，比如一个滑板车，一个自行车，根据用户的反馈我们再逐步把车的功能升级，最终变成用户想要的产品。

三、开发流程

云原生下的开发：

• 容器化技术
• 微服务技术
• WebIDE

团队分支策略：

有些团队会有一个专门的分支叫做release分支，大家都把代码合并到release分支，然后测试，发布，之后再把release分支合会master有些团队会直接把开发的分支合入master，然后再用某个master上的commit发布
之所以有各种各样的分支策略，就是因为我们在后续的测试和发布阶段要按照对应的分支和commit进行交付。

代码规范：
养成良好的注释习惯，超过三个月的代码，自己都会忘了当时在想什么
不要有魔法数字，魔法字符串
重复的逻辑抽象成公共的方法，不要copy代码
正确使用IDE的重构功能，防止修改错误

自测：

• 单元测试
• 功能环境测试
• 测试数据构造

文档：

• 大型改造需要有技术设计文档，方案评审
• 好的接口文档能更方便的和前端进行沟通

四、测试流程

你需要在写完每一段代码之后立刻测试这段代码，当完成了更多的代码时，就要做更多的测试。测试不是独立隔离的活动，它本身就是开发过程的一部分，质量不等于测试，当你把开发过程和测试放到一起，就像在搅拌机里混合搅拌那样，直到不能区分彼此的时候，你就得到了质量。 — 《Google 软件测试之道》

左边这个图是传统的测试金字塔模型，他的意思是:越底层的测试粒度越细，就需要越多的数量去覆盖所有场景，越顶层的测试越能用少量的case覆盖大多数场景。
但是有一个软件开发中的常识:越早发现的缺陷解决成本越低。

功能环境

• 需要一个能模拟线上的环境进行开发和测试
• 环境和环境之间能够隔离，不影响其他功能的开发和测试

集成环境

• 不同人开发的功能合并在一起测试，相互之间的影响可能产生缺陷
• 迭代发布的所有功能合并在一起测试，确保发布的所有功能之间的影响不产生缺陷

回归环境

• 确保新的功能不对老的功能产生影响
• 回归测试一般会借助自动化测试脚本

五、发布阶段

• 发布负责人
  负责按照计划执行发布
  需要通知各个相关人员发布进展
  观察各个服务的发布状态，及时处理异常
• 变更服务的相关RD
  按照上线checklist检查服务的日志，监控，响应上线过程中的告警·对于自己负责的改动，在小流量或者是预览环境进行功能验证.执行发布计划中的其他操作(如线上配置，数据处理等)
• 值班同学
  发布过程中的监控和告警需要特别关注，如果有异常需要立刻判断
  是否由变更引起
  如果有变更引起的告警或者用户反馈，需要及时中止发布
  

5.1、 蛮力发布

• 简单粗暴，直接用新版本覆盖老版本。
  
• 优点: 简单、成本低。
• 缺点:发布过程中服务会中断·出了问题会影响全部用户。
• 适用:测试环境部署,小公司或者非核心的业务服务。

5.2、金丝雀发布

由于金丝雀对瓦斯极其敏感，因此以前矿工开矿下矿洞前，先会放一只金丝雀进去探是否有有毒气体，看金丝雀能否活下来，金丝雀发布由此得名。

• 优点： 相对简单；能够用少量用户验证新版本功能；
• 缺点： 发布过程中服务会中断发现不了随用户量增大才会暴露的问题
• 适用： 测试环境部署；小公司或者非核心的业务服务

5.3、滚动发布

每个实例都通过金丝雀的方式逐步放大流量，对用户影响小，体验平滑。

• 优点：发布过程中，用户体验不会中断可以充分验证服务功能；
• 缺点：流程较复杂，对发布系统有比较高的要求发布速度较慢新老版本不兼容的情况不能使用。
• 适用：发布系统能力较强，可以平滑切换流量；发布自动化程度高，可以自动滚动。
  

5.4、蓝绿发布

把服务分成蓝绿两组，先把蓝组流量摘掉然后升级，只用绿组提供服务，之后切换全部流量，只用蓝组提供服务，然后升级绿组服务，最终两组全部升级。

• 优点: 发布速度快·流程相对简单。
• 缺点: 需要有一半机器承担所有流量的能力·出问题会影响全部用户。
• 适用: 服务器资源丰富。新老版本不能兼容的情况，需要一次性升级到新版

（对于流量承担的资源，其实也可以通过进行监控流量，选个流量少的时候进行发布。）

5.5、红黑发布

和蓝绿发布类似，但是发布时会动态扩容出一组新的服务，而不需要常备两组服务。

• 优点： 发布速度快流程相对简单
• 缺点： 对机器数量仍然有要求，需要能扩容一倍；出问题会影响全部用户
• 适用： 服务器资源丰富；新老版本不能兼容的情况，需要一次性升级到新版。

六、运维阶段

公司在发展过程中，逐渐形成了十分复杂的超大规模微服务体系。为了实现对这些复杂微服务的监控我们往往会在微服务中添加埋点采集Metrics、Logging、分布式Trace等多种数据。

总结

• 经过需求阶段我们讨论该做什么不该做什么
• 开发阶段我们按照规范去实现产品
• 测试阶段我们去验证产品，修改缺陷
• 发布阶段我们按照流程规范上线
• 运维阶段我们观察线上监控和日志