开发流程拆解与介绍

需求阶段

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

2.MVP(minimum viable product,最小化可行产品)思想 1）站在用户的角度思考

2）收集用户反馈，快速迭代

评估需求的方法——四象限法；

当你有很多任务的时候，把他们按照重要性和紧急程度分类

有些事情既重要又紧急，那么我们就应该先去做，不重要又不紧急的可以最后做

而有些事情虽然重要但是不紧急他们的优先级应该比那些紧急但是不重要的事情高，如果我们不去处理，后面他们就会变得又重要又紧急

先判断事情的重要性，再判断紧急程度

一个高效的占比，应该是大多数时间在处理重要但是不紧急的事情，因为一旦一件事情变成了紧急，那我们就容易犯错误，因此如果每天大部分时间都在处理重要且紧急的事情，那么其实是不健康的，容易累出病

开发阶段

云原生下的开发 传统虚拟机

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

容器化

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

单体架构

• 多个模块共同组成一个服务，服务体量较大
• 模块之间直接调用，不需要RPC通信
• 服务整体扩缩容量
• 多人开发一个代码仓库，需要充分集成测试 微服务架构 -各个功能在不同的服务中 -不同模块需要进行RPC通信 -不同模块可以独立扩缩容 -每个服务的代码仓库仅由少部分人维护

开发环境逐渐云原生化

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

团队的分支策略

• 团队专门搞一个release分支，大家都把代码合并到release分支，然后测试，发布，之后再把release分支回合master
• 有些团队会直接把开发的分支合并入master，然后再用某个master上的commit发布

代码规范、自测和文档

• 代码规范：良好的注释习惯，有复杂的地方时间长了自己都会忘
• 不要有魔法数字和魔法字符串
• 重复的逻辑可以抽象成公共的方法，不要到处copy代码
• 正确使用IDE功能进行重构，不要手动去编辑或者全局替换

自测：

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

文档：

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

测试阶段

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

功能环境

• 需要一个能模拟线上的环境进行开发和测试
• 环境和环境之间能够隔离，不影响其他功能的开发和测试 集成环境
• 不同人开发的功能合并在一起测试， 相互之间的影响可能产生缺陷
• 迭代发布的所有功能合并在一起测试， 确保发布的所有功能之间的影响不产生缺陷 回归环境
• 确保新的功能不对老的功能产生影响
• 回归测试一般会借助自动化测试脚本

发布阶段

发布过程中要做的事情

发布负责人

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

变更服务的相关RD

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

值班同学

• 发布过程中的监控和告警需要特别关注，如果有异常需要立刻判断

• 是否由变更引起

• 如果有变更引起的告警或者用户反馈，需要及时中止发布 各种发布模式-蛮力发布

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

• 优点:简单,成本低

• 缺点:发布过程中服务会中断,出了问题会影响全部用户

• 适用:测试环境部署,小公司或者非核心的业务服务

金丝雀发布

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

滚动发布

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

蓝绿发布

• 把服务分成蓝绿两组，先把蓝组流量摘掉然后升级，只用绿组提供服务，之后切换全部流量，只用蓝组提供服务，然后升级绿组服务，最终两组全部升级。
• 优点:发布速度快,流程相对简单
• 缺点:需要有一半机器承担所有流量的能力,出问题会影响全部用户
• 适用:服务器资源丰富,新老版本不能兼容的情况，需要一次性升级到新版

红黑发布

• 和蓝绿发布类似，但是发布时会动态扩容出一组新的服务， 而不需要常备两组服务。
• 优点:发布速度快,流程相对简单
• 缺点:对机器数量仍然有要求，需要能扩容-倍,出问题会影响全部用户
• 适用:服务器资源丰富
• 新老版本不能兼容的情况，需要一次性升级到新版

运维阶段：

负责服务的稳定性，确保服务可以不间断地为用户提供服务，我们观察线上监控和日志，来对公司硬件和软件进行维护。 硬件包括：机房、机柜、网线光纤、PDU、服务器、网络设备、安全设备等