[ 开发流程拆解与介绍 | 青训营笔记 ]

一. 需求阶段

1.1不要浪费时间讨论不应该存在的问题

特斯拉进行生产线自动化的时候，有一个零件的安装自动化总是出问题，特斯拉的工程师为了优化这个自动化流程，投入了大量的资金和精力。 后来马斯克问他们的技术人员，为什么需要这个零件，结果发现大家居然并不清楚。最后证明其实在电动车上，根本不需要这个零件。所以围绕着这个不应该存在的问题，进行了大量投入，造成了很多浪费。

1.2 MVP(minimum viable product,最小化可行产品)思想

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

1.2需求四象限

二. 开发阶段

2.1云原生下的开发

传统虚拟机

1. 在物理主机中虚拟出多个虚拟机，每个虚拟机拥有自己的操作系统
2. 运维人员负责维护和交付虚拟机
3. 每个虚拟机中都要安装相应的依赖环境

容器化

1. 容器是在操作系统中虚拟出来的
2. 通过cgroup, namespace和Union Mount等技术实现了容器之间的相互隔离，同时容器只有很低的开销
3. 应用和其依赖作为一个整体，打包成镜像交付

单体架构

1. 多个模块共同组成一个服务，服务体量较大
2. 模块之间直接调用，不需要RPC通信
3. 服务整体扩缩容量
4. 多人开发一个代码仓库，需要充分集成测试

微服务架构

1. 各个功能在不同的服务中
2. 不同模块需要进行RPC通信
3. 不同模块可以独立扩缩容
4. 每个服务的代码仓库仅由少部分人维护

开发环境逐渐云原生化

1. FaaS, PaaS等等技术，让开发逐渐从本地IDE向线上转变
2. 从入职领到电脑搭建完一套完整的开发环境需要很久，通过WEB IDE等技术，环境未来将会开箱即用

2.2团队的分支策略

2.3代码规范、自测和文档

代码规范

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

自测

1. 单元测试
2. 功能环境测试
3. 测试数据构造

文档

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

三. 测试阶段

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

——《Google软件测试之道》

3.1测试阶段

功能环境

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

集成环境

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

回归环境

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

四. 发布阶段

根据国际航空事故数据库中统计波音737系列飞机飞行事故数据，80%的事故发生在起飞和着陆阶段，按事故主要原因分类，人为因素占48%，机械原因只占20%。

飞行员起飞前的检查项，很多是有血淋淋的教训的。

而在互联网公司制定的发布规范中，许多规范的背后也是从严重事故总结而来的经验。

4.1发布过程中要做的事情

发布负责人

1. 负责按照计划执行发布
2. 需要通知各个相关人员发布进展
3. 观察各个服务的发布状态，及时处理异常

变更服务的相关RD

1. 按照上线checklist检查服务的日志，监控，响应上线过程中的告警
2. 对于自己负责的改动，在小流量或者是预览环境进行功能验证
3. 执行发布计划中的其他操作(如线 上配置，数据处理等)

值班同学

1. 发布过程中的监控和告警需要特别关注，如果有异常需要立刻判断
2. 是否由变更引起
3. 如果有变更引起的告警或者用户反馈，需要及时中止发布

4.2各种发布模式-蛮力发布

简单粗暴，直接用新版本覆盖老版本

优点

1. 简单
2. 成本低

缺点

1. 发布过程中服务会中断
2. 出了问题会影响全部用户

适用

1. 测试环境部署
2. 小公司或者非核心的业务服务

4.3各种发布模式-金丝雀发布

优点

1. 相对简单
2. 能够用少量用户验证新版本功能

缺点

1. 发布过程中服务会中断
2. 发现不了随用户量增大才会暴露的问题

适用

1. 测试环境部署
2. 小公司或者非核心的业务服务

4.4各种发布模式-滚动发布

优点

1. 发布过程中用户体验不会中断
2. 可以充分验证服务功能

缺点

1. 流程较复杂，对发布系统有比较高的要求
2. 发布速度较慢
3. 新老版本不兼容的情况不能使用

适用

1. 发布系统能力较强，可以平滑切换流量
2. 发布自动化程度高，可以自动滚动

4.5各种发布模式-蓝绿发布

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

优点

1. 发布速度快
2. 流程相对简单

缺点

1. 需要有一半机器承担所有流量的能力
2. 出问题会影响全部用户

适用

1. 服务器资源丰富
2. 新老版本不能兼容的情况，需要一次性升级到新版

4.6各种发布模式-红黑发布

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

优点

1. 发布速度快
2. 流程相对简单

缺点

1. 对机器数量仍然有要求，需要能扩容-倍
2. 出问题会影响全部用户

适用

1. 服务器资源丰富
2. 新老版本不能兼容的情况，需要一次性升级到新版

• 没有强大发布系统和服务器资源不足的公司一般使用蛮力发布或者金丝雀发布
• 有强大的发布工具和服务器资源充足的公司-般使用滚动发布和蓝绿发布

五. 运维阶段

六. 个人感悟

1. 多敲代码
2. 遇到困难，不要放弃，多去请教他人。