DevOps理念
DevOps理念
DevOps理念介绍
DevOps理念
DevSecOps理念
提高产品质量
1 自动化测试
2 持续集成/持续交付/持续部署
3 代码质量管理工具
4 程序员鼓励师
软件的生命周期
- 立项
- 产品原型图
- 需求碰撞
- 市场调研
- 市场需求
- 竞争对手
- 开发（开发环境）
- 功能拆分
- 登录功能
- 注册功能
- 交易功能
- 订单功能
- 购物功能
- 直播功能
- 物流功能
- 产品入库
- 产品出库
- .......等等
- 项目排期
- 项目开发
- 传统开发（低端公司）
- 敏捷开发（高端公司、scrum）
- 项目完成
- 代码集成（代码仓库：CI：Continunous Integration）
- 代码质检（sonarqube）
- 功能拆分
- 测试（测试环境）
- 测试用例
- 性能测试
- 功能测试（黑盒测试）
- 白盒测试
- 自动化测试
- 运维（预上线环境、生产环境）
- 代码交付（CD：Continunous Delivery）
- 代码部署（CD：Continunous Deployment）
- 服务维护
- 故障解决
- 技术支持
- 自动化运维
- 消亡（destroy）
什么是环境？
- 开发环境
- 测试环境
- 功能测试环境
- 性能测试环境
- 预生产环境（beta）
- 生产环境
什么是代码部署
简单的一句话：就是将开发写好的代码，通过一系列的手段，让它能够成功运行在我们的环境中。
其实我们很早就接触过。
比如：
- nginx
- 下载安装包（开发写好的代码）
- 构建代码
- 生成配置
- 编译安装
- 修改配置
- 启动程序
- MySQL
- wordpress
只不过不同的代码需要不同的环境。
那么在企业中也是一样的，比如开发写好的代码，需要用到nginx，那就要安装nginx，此时的nginx对于代码来说就是一个为了能够成功运行代码的中间件，需要MySQL，那么也是一样。
就好比，安装nginx，要先安装很多依赖，openssl-devel、zlib-devel、pcre-devel
曾老湿精髓名言：或许有些人绕不过来，当你成为架构师之后，一切皆为中间件，所有的应用，只是为了给我的代码提供一个运行环境而已，那些所谓的应用，都只是我代码的一个小小的依赖而已，或许我需要有个地方存储我的数据，那么作为开发人员，我可以任意选择地方，比如：文件中，world，execl都可以，但是为了产品的性能，安全，使我不得不选择一个当下热门的数据库，再或许，我的代码需要一个web环境，那么我可以自己用前端写一个web环境，然后把我的页面放进去，但是当下也有了很热门web程序，我们为什么不使用呢？
代码发布方式
应用程序升级面临最大挑战是新旧业务切换，将软件从测试的最后阶段带到生产环境，同时要保证系统不间断提供服务。
长期以来，业务升级渐渐形成了几个发布策略：蓝绿发布、金丝雀发布和滚动发布，目的是尽可能避免因发布导致的流量丢失或服务不可用问题。
- 手动发布
- 自动发布
蓝绿发布（AB发布）
项目逻辑上分为AB组，在项目系统时，首先把A组从负载均衡中摘除，进行新版本的部署。B组仍然继续提供服务。
当A组升级完毕，负载均衡重新接入A组，再把B组从负载列表中摘除，进行新版本的部署。A组重新提供服务。
最后，B组也升级完成，负载均衡重新接入B组，此时，AB组版本都已经升级完成，并且都对外提供服务。
特点：
- 如果出问题，影响范围较大；
- 发布策略简单；
- 用户无感知，平滑过渡；
- 升级/回滚速度快。
缺点：
- 需要准备正常业务使用资源的两倍以上服务器，防止升级期间单组无法承载业务突发；
- 短时间内浪费一定资源成本；
- 基础设施无改动，增大升级稳定性。
蓝绿发布在早期物理服务器时代，还是比较昂贵的，由于云计算普及，成本也大大降低。
灰度发布（金丝雀发布）
灰度发布是指在黑与白之间，能够平滑过渡的一种发布方式。灰度发布是增量发布的一种类型，灰度发布是在原有版本可用的情况下，同时部署一个新版本应用作为“金丝雀”（金丝雀对瓦斯极敏感，矿井工人携带金丝雀，以便及时发发现危险），测试新版本的性能和表现，以保障整体系统稳定的情况下，尽早发现、调整问题。
从负载均衡列表中移除掉“金丝雀”服务器。
升级“金丝雀”应用（排掉原有流量并进行部署）。
对应用进行自动化测试。
将“金丝雀”服务器重新添加到负载均衡列表中（连通性和健康检查）。
如果“金丝雀”在线使用测试成功，升级剩余的其他服务器。（否则就回滚）
特点：
- 保证整体系统稳定性，在初始灰度的时候就可以发现、调整问题，影响范围可控；
- 新功能逐步评估性能，稳定性和健康状况，如果出问题影响范围很小，相对用户体验也少；
- 用户无感知，平滑过渡。
缺点：
- 自动化要求过高（流水线发布）
滚动发布
滚动发布是指每次只升级一个或多个服务，升级完成后加入生产环境，不断执行这个过程，直到集群中的全部旧版本升级新版本。
红色：正在更新的实例
蓝色：更新完成并加入集群的实例
绿色：正在运行的实例
特点：
- 用户无感知，平滑过渡；
- 节约资源。
缺点：
- 部署时间慢，取决于每阶段更新时间；
- 发布策略较复杂；
- 无法确定OK的环境，不易回滚。
