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