一、需求阶段
不要浪费时间讨论不应该存在的问题
如何评估一个需求：
MVP（minimum viable product，最小化可行产品）思想
*站在用户的角度思考
*收集用户反馈，快速迭代
二、开发阶段
云原生技术的发展，深刻改变了后端开发的工作。“大人，时代变了”。
1、云原生下的开发
传统虚拟机-->容器化
单体架构-->微服务架构
开发环境逐渐云原生化
FaaS，PaaS等等技术，让开发逐渐从本地IDE向线上转变
从入职领到电脑搭建完一套完整的开发环境需要很久，通过WEB IDE等技术，环境未来将会开箱即用
2、团队的分支策略
Q1：多个团队成员之间各自用什么分支开发?
Q2：修改之间有冲突怎样解决？
Q3：出了问题的代码如何回退到之前的版本？
3、代码规范、自测和文档
代码规范
*养成良好的注释习惯，超过三个月的代码，自己都会忘记当时在想什么
*不要有魔法数字，魔法字符串
*重复的逻辑抽象成公共得到方法，不要copy代码
*正确使用IDE的重构功能，防止修改错误
自测
*单元测试
*功能环境测试
*测试数据构造
文档
*大型改造需要有技术设计文档，方案审评
*好的接口文档能更方便的和前端进行沟通
三、测试阶段
你需要在写完每一段代码之后立刻测试这段代码，当完成了更多的代码时，就要做更多的测试。测试不是独立隔离的活动，它本身就是开发过程的一部分，质量不等于测试，当你把开发过程和测试放到一起，就像在搅拌机里混合搅拌那样，直到不能区分彼此的时候，你就得到了质量。——《Google 软件测试之道》
越早发现缺陷修复的成本越低
*功能环境
·需要一个能模拟线上的环境进行开发和测试
·环境和环境之间能够隔离，不影响其他功能的开发和测试
*集成环境
·不同人开发的功能合并在一起测试，相互之间的影响可能产生缺陷
·迭代发布的所有功能合并在一起测试，确保发布的所有功能之间的影响不产生缺陷
*回归环境
·确保新的功能不对老的功能产生影响
·回归测试一般会借助自动化测试脚本
四、发布阶段
在互联网公司制定的发布规范中，许多规范的背后是从严重事故总结而来的经验
1、发布过程中要做的事情
发布负责人
·负责按照计划执行发布
·需要通知各个相关人员发布进展
·观察各个服务的发布状态，及时处理异常
变更服务的相关 RD
·按照上线checklist检查服务的日志，监控，响应上线过程的告警
·对于自己负责的改动，在小流量或者是预览环境进行功能验证
·执行发布计划中的其他操作（如线上配置，数据处理等）
值班同学
·发布过程中的监控和告警需要特别关注，如果有异常需要立刻判断是否由变更引起
·如果有变更引起的告警或者用户反馈，需要及时中止发布
2、各种发布模式
（1）蛮力发布
#简单粗暴，直接用新版本覆盖旧版本
优点
·简单
·成本低
缺点
·发布过程中服务会中断
·出了问题会影响全部用户
适用
·测试环境部署
·小公司或者非核心的业务服务
（2）金丝雀发布
#由于金丝雀对瓦斯极其敏感，因此以前矿工开矿下矿洞之前，先会放一只金丝雀进去探是否有有毒气体，看金丝雀能否活下来，金丝雀发布由此得名。
优点
·相对简单
·能够用少量用户验证新版本功能
缺点
·发布过程中服务会中断
·发现不了随用户量增大才会暴露的问题
适用
·测试环境部署
·小公司或者非核心的业务服务
（3）滚动发布
#每个实例都通过金丝雀的方式逐步放大流量，对用户影响小，体验平滑。
优点
·发布过程中用户体验不会中断
·可以充分验证服务功能
缺点
·流程较复杂，对发布系统有比较高的要求
·发布速度较慢
·新老版本不兼容的情况不能使用
适用
·发布系统能力较强，可以平滑切换流量
·发布自动化程度高，可以自动滚动
（4）蓝绿发布
#把服务分成蓝绿两组，先把蓝组流量摘掉然后升级，只用绿组提供服务，之后切换全部流量，只用蓝组提供服务，然后升级绿组服务，最终两组全部升级。
优点
·发布速度快
·流程相对简单
缺点
·需要有一半机器承担所有流量的能力
·出问题会影响全部用户
适用
·服务器资源丰富
·新老版本不能兼容的情况，需要一次性升级到新版
（5）红黑发布
#和蓝绿发布类似，但是发布时会动态扩容出一组新的服务，而不需要常备两组服务。
优点
·发布速度快
·流程相对简单
缺点
·对机器数量仍然有要求，需求能扩容一倍
·出问题会影响全部用户
适用
·服务器资源丰富
·新老版本不能兼容的情况，需要一次性升级到新版
小结：
·没有强大发布系统和服务器资源不足的公司一般使用蛮力发布或者金丝雀发布
·有强大的发布工具和服务器资源充足的公司一般使用滚动发布和蓝绿发布
五、运维阶段
公司在发展过程中，逐渐形成了十分复杂的超大规模微服务体系。为实现对这些复杂微服务的监控，我们往往会在微服务中添加埋点采集 Metrics、Logging、分布式 Trace 等多种数据。
