**一、**DevOps 简介
指导思想，并不是技术
**背景：**实战中企业的IT职能划分：研发部门：甲方（产品经理）、乙方（项目经理）------开发部门（用什么开发框架、什么语言、是否做微服务或单体架构、开发周期、开发模式）------OPS运维部门：分交付上线和部署上线，上线到测试环境或生产环境。包括是否做蓝绿部署、灰度部署、滚动发布，上线到哪个平台，怎么负载均衡、上线后的稳定性，监控时长。------测试部门：开发周期中跟随开发人员进行质量监测，工作是编写测试用力、提交bug漏洞、对代码结构做质量检测。测试分为黑盒（只测功能）和白盒测试（编写代码能力，查看代码功能）。
运维扩展岗位：实施、驻场、技术支持。
1. 传统开发模型
①：软件开发生命周期（五个阶段重）
阶段 1: 计划和需求分析 (Planning and Requirement Analysis)
每个软件开发生命周期模型都从分析开始，过程的利益相关者讨论对最终产品的要求。此阶段的目标是系统要求的详细定义。此外，还需要确保所有流程参与者都清楚地了解任务以及每个需求将如何实施。通常，讨论涉及质量保证专家，如果有必要，他们甚至可以在开发阶段干预过程中的添加。
阶段 2: 设计项目架构 (Project Architecture)
在软件开发生命周期的第二阶段，开发人员实际上正在设计架构。所有利益相关者（包括客户）都会讨论此阶段可能出现的所有不同技术问题。此外，还定义了项目中使用的技术，团队负载，限制，时间范围和预算。最合适的项目决策是根据定义的要求做出的。
阶段 3: 开发和编程 (Development and Coding)
在批准要求后，该过程进入下一阶段 - 实际开发。程序员从这里开始编写源代码，同时牢记先前定义的需求。系统管理员调整软件环境，前端程序员开发程序的用户界面以及与服务器交互的逻辑。编程本身一般会用四个阶段:算法开发,源代码编写,编译,测试和调试
阶段 4: 测试 (Testing)
测试阶段包括调试过程。开发过程中遗漏的所有代码缺陷都会在此处检测到，记录下来并传回给开发人员进行修复。重复测试过程，直到删除所有关键问题并且软件工作流程稳定。
阶段 5: 部署 (Deployment)
当程序最终确定并且没有关键问题时 - 是时候为最终用户启动它了。新程序版本发布后，技术支持团队加入。该部门提供用户反馈; 在利用期间咨询和支持用户。此外，此阶段还包括所选组件的更新，以确保软件是最新的，并且不会受到安全漏洞的影响。
②： SDLC****模型 (Software Development Life cycle Model)
从第一个也是最古老的"瀑布式"SDLC模型演变而来，其种类不断扩大。比较常见的SDLC模型如下
瀑布模型 (Waterfall Model)
迭代模型 (Iterative Model)
螺旋模型 (Spiral Model)
V形模型 (V-Shape Model)： 单元测试，集成测试，系统测试，验收测试;适合高质量的软件环境，比如微软。
敏捷模型 (Agile Model)
【注】：
① 瀑布模型要求很严格，最终效果要和期望效果一致，缺点是开发周期特别长，每个阶段必须完成相应的功能。
② 敏捷开发， 迭代开发和增量开发。好处在于哪里出问题就只修改一小部分，不用从头开始。
迭代开发：在之前的基础上进行迭代开发。
增量开发：在某些迭代开发基础上完善相关功能。软件的每个版本，按照新增功能来划分迭代。
瀑布模型：
瀑布模型是早期实现的开发模型,是一个级联SDLC模型，其中开发过程看起来像制造业的流水线，一步一步地进行分析，预测，实现，测试，实施和支持阶段。该SDLC模型包括完全逐步执行每个阶段。该过程严格记录并预定义，具有该软件开发生命周期模型的每个阶段所期望的功能。
敏捷开发：
敏捷开发的核心是迭代开发(lterative Development)与增量开发(IncrementalDevelopment) 。
迭代开发：
对于大型软件项目，传统的开发方式是采用一个大周期(比如一年或数年)进行开发，整个过程就是一次"大开发"。迭代开发的方式则不一样，它将开发过程拆分成多个小周期，即一次"大开发"变成多次"小开发"，每次小开发都是同样的流程，所以看上去就好像重复在做同样的步骤
比如: 某公司生产手机,第一次生产1代(比较简陋),逐年再生产2代,再到3代等
增量开发:
软件的每个版本，都会新增一个可以被用户感知到的完整功能。也就是说，按照新增功能来划分迭代。
比如: 房地产公司开发一个小区。如果采用增量开发的模式，该公司第一个迭代就是交付一期楼盘，第二个迭代交付二期楼盘...每个迭代都是完成一栋完整的楼盘。而不是第一个迭代挖好所有楼的地基，第二个迭代建好每栋楼的骨架，第三个迭代架设屋顶.....
虽然敏捷开发将软件开发分成多个迭代，但是也要求，每次迭代都是一个完整的软件开发周期，必须按照软件工程的方法论，进行正规的流程管理。
敏捷开发和瀑布开发的区别：
①瀑布开发周期很长，敏捷开发周期短。
②瀑布开发开发模式是线性的，很难看到结果，过程中出错风险大。敏捷开发是小步快跑方式，基于增量和迭代方式进行开发，每次开发关联相关测试，
优势如下：
尽早交付 , 加快资金回笼
降级风险 , 及时了解市场需求
提高效率 , 阶段性功能折分及快速质量反馈
敏捷开发大幅提高了开发团队的工作效率，让版本的更新速度变得更快。
很多人可能会觉得，"更新版本的速度快了，风险不是更大了吗？"其实，事实并非如此。
敏捷开发可以帮助更快地发现问题，产品被更快地交付到用户手中，团队可以更快地得到用户的反馈，从而进行更快地响应。而且， DevOps 小步快跑的形式带来的版本变化是比较小的，风险会更小（如下图所示）。即使出现问题，修复起来也会相对容易一些。
devops在现代化云原生平台的应用性
2. DevOps 介绍（什么是 DevOps ）
DevOps 即开发 Development 和 Operations 运维的缩写。
DevOps是一组过程、方法与系统的统称，用于促进开发、技术运营和质量保障（QA）部门之间的沟通、协作与整合。
DevOps 是针对开发人员、运维人员和测试人员的一种工作理念，是软件在应用开发、代码部署和质量测试等整条生命周期中协作和沟通的最佳实践
DevOps 强调整个组织的所有相关部门的紧密合作以及交付和基础设施变更的自动化、从而实现持续集成、持续部署和持续交付的目标
基于CICD技术，去实现devops
补充：
构建：将开发好的代码测试、编译、打包、部署、上线、运营监控的整体流程。
基于CICD技术去实现devops理念，CICD是一个技术栈。
Git是代码控制、版本控制系统；gitlab私有代码仓库；maven实现编译流程；Nexus程序包仓库；docker容器和镜像制作；harbor私有镜像仓库；jmeter做性能测试，压力测试；
其中开发人员做应用镜像，运维人员做系统镜像和环境镜像。
3 ：为什么要 DevOps
传统的模式是开发人员只关心开发程序，追求功能的变化和实现
运维只负责基础环境管理和代码部署及监控等，更看重应用的稳定运行
双方缺少一个共同的目标
DevOps 强调团队协作、相互协助、持续发展，实现团队作战，即无论是开发、运维还是测试，都为了最终的代码发布、持续部署和业务稳定而付出各自的努力，从而实现产品设计、开发、测试和部署的良性循环，实现产品的最终持续交付。
想要将DevOps真正落地，首先第一点，是思维转变，也就是"洗脑"。不仅是运维的要洗，开发的也要洗。员工要洗，领导更要洗。DevOps并不仅仅是组织架构变革，更是企业文化和思想观念的变革。如果不能改变观念，即使将员工放在一起，也不会产生火花。除了洗脑之外，就是根据DevOps思想重新梳理全流程的规范和标准。在DevOps的流程下，运维人员会在项目开发期间就介入到开发过程中，了解开发人员使用的系统架构和技术路线，从而制定适当的运维方案。而开发人员也会在运维的初期参与到系统部署中，并提供系统部署的优化建议。DevOps的实施，促进开发和运维人员的沟通，增进彼此的理（gan）解（qing）。
4.DevOps 相关的软件
DevOps 涉及的四大相关平台
项目管理：如：Jira,禅道
代码托管：如：Gitlab,SVN
持续交付：如：Jenkins,Gitlab
运维平台：如：腾讯蓝鲸,Spug等
持续集成、持续交付和持续部署 CICD （重）
最初是瀑布模型，后来是敏捷开发，现在是DevOps，这是现代开发人员构建出色的产品的技术路线。随着DevOps的兴起，出现了持续集成（Continuous Integration）、持续交付（Continuous Delivery） 、持续部署（Continuous Deployment） 的新方法。传统的软件开发和交付方法正在迅速变得过时。从以前的敏捷时代，大多数公司会每月，每季度，每两年甚至每年发布部署/发布软件。然而现在在DevOps时代，每周，每天，甚至每天多次是常态。当SaaS正在占领世界时，尤其如此，您可以轻松地动态更新应用程序，而无需强迫客户下载新组件。很多时候，他们甚至都不会意识到正在发生变化。开发团队通过软件交付流水线（Pipeline）实现自动化，以缩短交付周期，大多数团队都有自动化流程来检查代码并部署到新环境。CI/CD 是一种通过在应用开发阶段引入自动化来频繁向客户交付应用的方法。CI/CD 的核心概念是持续集成、持续交付和持续部署。作为一个面向开发和运营团队的解决方案，CI/CD 主要针对在集成新代码时所引发的问题具体而言，CI/CD 可让持续自动化和持续监控贯穿于应用的整个生命周期（从集成和测试阶段，到交付和部署）。这些关联的事务通常被统称为"CI/CD 管道"，由开发和运维团队以敏捷方式协同支持。和部署）。这些关联的事务通常被统称为"CI/CD 管道"，由开发和运维团队以敏捷方式协同支持。 此描述来源红帽官网 一文带你看懂 CI/CD 是什么？
①持续集成 (CI-Continuous Integration)
集成指将多位开发者的开发代码提交后,合并集成在一起,存放在代码库的过程,并且后续还会不断的迭代更新代码
持续集成是指多名开发者在开发不同功能代码的过程当中，可以频繁的将代码行合并到一起并切相互不影响工作。很多情况下每天都要进行几次，主要目的是尽早发现集成错误，使团队更加紧密结合，更好地协作。
CI属于开发人员的自动化流程。成功的 CI 意味着应用代码的新更改会定期构建、测试并合并到共享存储库中。该解决方案可以解决在一次开发中有太多应用分支，从而导致相互冲突的问题。
持续集成强调开发人员提交了新代码之后，立刻进行构建、（单元）测试。根据测试结果，可以确定新代码和原有代码能否正确地集成在一起。通过持续集成可以自动编译、打包、签名项目，配合单元测试可以实现持续集成+自动化测试。让工程师从重复而又枯燥的手动打包完全解放出来，让工程师能更加专注于代码本身，最大限度的减少误操作风险，降低修复错误代码的成本，大幅提高工作效率。
CICD 流程（重）
开发人员不断的进行代码提交到本地，再提交到运程的代码仓库服务器
Jenkins作为持续集成工具，使用Git工具到Git仓库拉取代码到集成服务器，代码测试与审查，再配合JDK，Maven，Go等软件完成代码编译，测试，打包等工作，在这个过程中每一步如果出错，都需要重新再执行一次整个流程。
Jenkins把生成的软件jar或war包等分发到测试服务器或者生产服务器，测试人员或用户就可以访问应用。
②：持续交付 (CD-Continuous Delivery) 测试环境
完成 CI 中构建及单元测试和集成测试的自动化流程后，持续交付可以自动的将已验证的代码发布到存储库。为了实现高效的持续交付流程，务必要确保 CI 已内置于开发管道。持续交付的目标是拥有一个可随时部署到生产环境的代码库。
在持续交付中，每个阶段（从代码更改的合并，到生产就绪型构建版本的交付）都涉及测试自动化和代码发布自动化。在流程结束时，运维团队可以快速、轻松地将应用部署到生产环境中。
持续交付完成了构建和测试过程细致的自动化，但是如何发布以及发布什么仍然是需要人工操作，持续部署可以改变这一点。
持续集成（CONTINUOUS INTEGRATION，CI）指的是开发人员频繁的（一天多次的）将所有开发者的工作合并到主干上。这些新提交在最终合并到主线之前，都需要通过编译和自动化测试流进行验证，以保障所有的提交在合并主干之后的质量问题，对可能出现的一些问题进行预警。持续集成的核心在于确保新增的代码能够与原先代码正确的集成。
持续交付在持续集成的基础上，将集成后的代码部署到更贴近真实运行环境的「类生产环境」（production-like environments）中。比如，我们完成单元测试后，可以把代码部署到连接数据库的Staging 环境中更多的测试。如果代码没有问题，可以继续手动部署到生产环境中。此方式是当前普遍采用的方式
③：持续部署 (CD-Continuous Deployment) 开发环境
对于一个成熟的 CI/CD 管道来说，最后的阶段是持续部署。作为持续交付(自动将生产就绪型构建版本发布到代码存储库)的进一步延伸，持续部署可以自动将应用发布到生产环境。由于在生产之前的管道阶段没有手动风控，因此持续部署在很大程度上都得依赖精心设计的测试自动化。实际上，持续部署意味着开发人员对应用的更改在编写后的几分钟内就能生效（假设它通过了自动化测试）。这更加便于持续接收和整合用户反馈。总而言之，所有这些 CI/CD 的关联步骤都有助于降低应用的部署风险，因此更便于以小件的方式（而非一次性）发布对应用的更改。不过，由于还需要编写自动化测试以适应 CI/CD 管道中的各种测试和发布阶段，因此前期投资还是会很大。持续部署是基于某种工具或平台实现代码自动化的构建、测试和部署到线上环境以实现交付高质量的产品,持续部署在某种程度上代表了一个开发团队的更新迭代速率。与持续集成相比，持续交付（CONTINUOUS DELIVERY，CD）的侧重点在于交付，其核心对象不在于代码，而在于可交付的产物。由于持续集成仅仅针对于新旧代码的集成过程执行了一定的测试，其变动到持续交付后还需要一些额外的流程。与持续集成相比较，持续交付添加了测试Test->模拟Staging->生产Production的流程，也就是为新增的代码添加了一个保证：确保新增的代码在生产环境中是可用的。在持续交付的基础上，把部署到生产环境的过程自动化。如果你对比上图持续部署就可以发现持续部署和持续交付的区别就是最终部署到生产环境是自动化的。因为自动发布存在较大的风险,当前采用此方式较少
持续交付的目的就是拥有一个可随时部署到生产环境的代码库，并确保以最少的工作量部署新代码。可以理解为持续交付是交付到测试环境；持续部署是部署到生产环境。
CI属于开发人员的自动化流程；CD属于运维人员的自动化。
Devops的核心功能是实现CICD流水线的自动化。
持续交付已自动化，持续部署不能完全自动化，仍需手动部署到生产环境。
④： CICD 流程过程和架构
应用部署发展阶段
开发人员自行上传代码
早期项目,没有专业的运维人员,运维的工作由开发兼职完成,项目发布很不专业,很容易出错,也是最原始的方式
开发人员先将代码发给运维,再由运维人员手动上传至生产环境专业的运维人员完成应用的部署,每次项目发布都由运维人员一步一步手动实现,效率低下且容易出错，运维利用脚本和自动化运维工具实现部署，由运维人员编写Shell,Python等脚本或利用自动化运维工具,如Ansible等实现半自动化应用部署,效率很高,但对技术的专业性有较高要求通过 Web 等 GUI 界面实现一键自动化部署，可以通过开源或自研的运维平台实现方便的应用部署,操作容易,效率高,但需要提前构建运维平台
⑤：常见的 CICD 工具
K8s环境的CICD是将代码制作成镜像后发布到各个pod中，如果是openstack，就是将代码发布到一个个实例中；普通模式是将代码发布到服务器中。
整个CICD流程核心是Jenkins，它实质没有特定功能，通过调用别的软件去执行某些相应功能。
⑦： Kubernetes 环境的 CICD
⑧：CICD流程结合服务器架构
二、版本控制系统 VCS 详解
版本控制系统（Version Control System，VCS）是一种软件，可以帮助软件团队的开发人员协同工作，并存档他们工作的完整历史记录。
为什么使用 VCS ?
在实际开发过程中，经常会有这种需求或问题
代码可能被破坏,比如误删除等,希望还能找回
代码出现了严重的Bug,希望回滚至数周前的旧代码
需要在已经发布的程序中添加新的功能，如果测试验证后没有问题，才会使用新的代码，而在测试
验证期间，不能影响原来的代码
同一个软件需要有多个版本并行开发,满足不同的应用需求
实际项目开发基本都是多个人合作完成，在多个人写代码时，就牵扯到代码合并成一份的问题。
1 ：版本控制系统分类
①：本地版本控制系统
第一代版本控制系统被称为本地版本控制系统。通过加锁将并发执行转换成顺序执行。 一次只能有一个人处理文件。
具体流程如下：首先，应该把文件放在一个服务器上，方便使用者上传或下载文件；其次，任何人想对文件修改时，需要先把这个文件加锁，通过checkout指令，使得其他人无法修改；最后，当修改完成之后，需要释放锁，通过checkin指令，形成一个新的版本，存放到服务器端。
第一代版本控制系统主要有 RCS、SCCS（1972年发布）和 DSEE（被认为是 Atria ClearCase 的前身）。目前，有些项目还在使用！
用户想要完成任何的提交和回滚都依赖于连接集中的代码服务器才能实现,比如下班回家后,如果无法连接至代码的服务器,将无法提交代码；此外此服务器还存在单点问题
③：分布式版本控制系统
在每个用户都有一个完整的服务器，然后再部署一个中央服务器；用户可以先将代码提交到本地，没有网络也可以先提交到本地，然后在有网络的时候再提交到中央服务器，这样就大大方便了开发者
相比集中式的版本控制系统，工作的时候需要先从中央服务器获取最新的代码，改完之后需要提交，如果是一个比较大的文件则需要足够快的网络才能快速提交完成,而使用分布式的版本控制系统，每个用户都是一个完整的版本库，即使没有中央服务器也可以提交代码或者回滚，最终再把改好的代码提交至中央服务器进行合并即可。
svn集中式版本控制系统和git分布式版本控制系统的区别：
① svn集中式需要连网络到中央服务器；而git分布式代码的提交和回滚是不依赖网络的，不用依赖中央服务器，只有在将最终成品提交到中央服务器需要网络。
②git是分布式的,svn是集中式的
git是每个历史版本都存储完整的文件,便于恢复,svn是存储差异文件
git可离线完成大部分操作,svn则不能
git有着更优雅的分支和合并实现
git有着更强的撤销修改和修改历史版本的能力
git速度更快,效率更高
2 ：常见版本控制系统简介
①集中式版本控制系统 svn
SVN 依赖于网络，需要在各个开发主机上安装客户端软件,并且在一台服务器集中进行版本管理和存储.目前依然有部分公司在使用
优点：
管理方便，逻辑明确，符合一般人思维习惯。
易于管理，集中式服务器更能保证安全性。
代码一致性非常高。
适合开发人数不多的项目开发。
缺点：
服务器压力太大，数据库容量暴增。
如果不能连接到服务器上，基本上不可以工作，如果服务器不能连接上，就不能提交，还原，对比等等。
不适合开源开发（开发人数非常非常多，但是Google app engine就是用svn的）。但是一般集中式管理的有非常明确的权限管理机制（例如分支访问限制），可以实现分层管理，从而很好的解决开发人数众多的问题。
②分布式版本控制系统 git
在 Linux 开源的初期，Linux 开源项目的代码是 linus 本人通过 linux 命令 diff 和 patch 两条命令手动完成。随着 Linux 代码越来越壮大，靠 Linus 一个人来手动合并已经不现实。2002 年，Linus 选择了一个商业版本控制系统 BitKeeper 作为 Linux 内核的代码管理工具（BitKeeper 的开发商 BitMover 授权linux 社区免费使用）。但是，免费使用是有很多的限制的，因此 linux 社区的大佬开始破解BitKeeper。其中，samba 的作者 andrew 破解成功了。但是被 BitMover 公司发现，收回免费使用权。
迫不得已，Linus 选择了自己开发一个分布式版本控制工具以替代 BitKeeper。linus 闭关一个月，写出了 Git。在一个月后，Git 成功接管了 Linux 社区的版本控制工作，并且开始开源。
Git 重要特性:
在本地就可以完成提交,因此不需要网络,提交完成后,可以有网络环境时,再同步到远程仓库服务器
优点：
适合分布式开发，强调个体。
公共服务器压力和数据量都不会太大。
速度快、灵活。
任意两个开发者之间可以很容易的解决冲突。
支持离线工作。
缺点：
不符合常规思维。
学习周期相对而言比较长。
代码保密性差，一旦开发者把整个库克隆下来就可以完全公开所有代码和版本信息。
③： Github 网站
2008年1月，Wanstrath和Preston-Werner推出使用Ruby on Rails编写而成的GitHub的个人测试版。2月，他们又增加了第三位联合创始人PJ Hyett，到2008年3月，GitHub的beta版已经拥有了2000名用户。GitHub于2008年4月推出公共版本，然后逐渐在开发者社区中流行起来，到2009年7月，用户数量达到了10万。
由于GitHub在软件开发人员中很受欢迎，成立后的四年，GitHub通过向个人程序员和企业收取每月访问平台的费用，在没有外部资金的情况下得以生存下来。
GitHub网站为开源项目免费提供Git存储，无数开源项目开始迁移至GitHub，包括jQuery，PHP，Ruby等等。GitHub同时提供付费账户和免费账户。这两种账户都可以创建公开的代码仓库，但是只有付费账户可以创建私有的代码仓库。
2018年6月5日 微软花费 75 亿美元收购 GitHub
2019年1月7日 免费的 GitHub 用户现在可以获得不受限制的私人项目，最多可以有三个协同合作者
2005年4月3日，开始开发 Git。
2005年4月6日，项目发布。
2005年4月7日，Git就可以作为自身的版本控制工具了。
2005年4月18日，发生第一个多分支合并。
2005年4月29日，Git 的性能就已经达到了 Linus 的预期。
2005年6月16日，Linux 2.6.12 发布，那时 Git 已经在维护 Linux 核心的源代码了。
2005年7月26日，Linus 功成身退，将 Git 的维护交给另外一个 Git 的主要贡献者 Junio C Hamano。
2016年5月，BitKeeper宣布使用 Apache 2.0许可证开源。
2020年4月14日 GitHub宣布向所有用户和团队提供不限制协作人数的私有仓库，同时GitHub的核心功能对所有人免费开放
3 ：常见的软件部署模式（重）
①：蓝绿部署 Blue-green Deployments
蓝绿部署指的是不停止老版本代码(不影响上一个版本访问)，而是在另外一套环境部署新版本然后进行测试，测试通过后将用户流量切到新版本，其特点为业务无中断，升级风险相对较小。但本方式成本较高,一般小公司较少使用
蓝绿色部署是一种部署策略，利用两种相同的环境，即"蓝色"（又名预发布）环境和"绿色"（又名生产）环境，具有不同版本的应用程序或服务。质量保证和用户接受度测试通常在承载新版本或更改的蓝色环境中进行。一旦蓝色环境中测试并接受新的变化，用户流量就会从绿色环境转变为蓝色环境。然后，一旦部署成功，您可以切换到新环境。
具体过程：
1、当前版本(V1)业务正常访问
2、在另外一套环境部署新代码版本(V2)，代码可能是增加了功能或者是修复了某些bug
3、测试通过之后将用户请求流量切到新版本环境
4、观察一段时间，如有异常直接切换旧版本
5、下次升级，将旧版本(V2)升级到新版本(V3)命名卷: 指定数据卷的名称和容器路径的挂载关系，此方式会创建命名数据卷
蓝绿部署适用的场景：
1、不停止老版本，额外部署一套新版本，等测试确认新版本正常后，才将用户请求切换至新版本，如果有问题，切换回老版本
2、蓝绿发布是一种用于升级与更新的发布策略，部署的最小维度是容器，而发布的最小维度是应用。
3、蓝绿发布对于增量升级有比较好的支持，但是对于涉及数据表结构变更等等不可逆转的升级，并不完全合适用蓝绿发布来实现，需要结合一些业务的逻辑以及数据迁移与回滚的策略才可以完全满足需求。
②：金丝雀 ( 灰度 ) 发布 Canary Deployment
金丝雀发布也叫灰度发布，是指在黑与白之间，能够平滑过渡的一种发布方式，灰度发布是增量发布（例如：2%、25%、75%、100%）进行更新)的一种类型，灰度发布是在原有版本可用的情况下，同时部署一个新版本应用作为"金丝雀"(小白鼠)，测试新版本的性能和表现，以保障整体系统稳定的情况下，尽早发现、调整问题。因此，灰度发布可以保证整体系统的稳定，在初始灰度的时候就可以发现、调整问题，以保证其影响度。此方式在实际生产中使用较为普遍
金丝雀/灰度发布步骤组成：
1、准备好部署各个阶段的工件，包括：构建组件，测试脚本，配置文件和部署清单文件。
2、从负载均衡列表中移除掉"金丝雀"服务器（选择全部服务器中的一部分）。
3、升级"金丝雀"应用（排掉原有流量并进行部署）。
4、对应用进行自动化测试。
5、将"金丝雀"服务器重新添加到负载均衡列表中（连通性和健康检查）。
6、如果"金丝雀"在线使用测试成功，升级剩余的其他服务器。否则就回滚回旧版本
金丝雀/灰度发布部署适用的场景：
1、不停止老版本，额外搞一套新版本，不同版本应用共存。
2、灰度发布中，常常按照用户设置路由权重，例如90%的用户维持使用老版本，10%的用户尝鲜新版
本。
3.经常与A/B测试一起使用，用于测试选择多种方案。
A/B测试是效果测试，同一时间有多个版本的服务对外服务，这些服务都是经过足够测试，达到了上线标准的服务，有差异但是没有新旧之分（它们上线时可能采用了蓝绿部署的方式）。
A/B测试关注的是不同版本的服务的实际效果，譬如说转化率、订单情况等。
A/B测试时，线上同时运行多个版本的服务，这些服务通常会有一些体验上的差异，譬如说页面样式、颜色、操作流程不同。相关人员通过分析各个版本服务的实际效果，选出效果最好的版本。
③：滚动发布 ( 更新 )
滚动发布故名思议，就是逐步升级服务中的节点
滚动发布是指每次只升级一个或多个服务实例，升级完成后加入生产环境，不断执行这个过程，直到集群中的全部旧版本升级新版本。
在金丝雀发布基础上的进一步优化改进，是一种自动化程度较高的发布方式，用户体验比较平滑，是目前成熟型技术组织所采用的主流发布方式。
①定义
滚动发布：一般是取出一个或者多个服务器停止服务，执行更新，并重新将其投入使用。周而复始，直到集群中所有的实例都更新成新版本。
②特点
这种部署方式相对于蓝绿部署，更加节约资源------它不需要运行两个集群、两倍的实例数。我们可以部分部署，例如每次只取出集群的 20% 进行升级。
③部署过程
滚动式发布一般先发1台，或者一个小比例，如2% 服务器，主要做流量验证用，类似金丝雀 (Canary) 测试。
滚动式发布需要比较复杂的发布工具和智能 LB，支持平滑的版本替换和流量拉入拉出。
每次发布时，先将老版本V1流量从LB上摘除，然后清除老版本，发新版本V2，再将LB流量接入新版本。这样可以尽量保证用户体验不受影响。
一次滚动式发布一般由若干个发布批次组成，每批的数量一般是可以配置的（可以通过发布模板定义）。例如第一批 1 台（金丝雀），第二批 10%，第三批 50%，第四批 100%。每个批次之间留观察间隔，通过手工验证或监控反馈确保没有问题再发下一批次，所以总体上滚动式发布过程是比较缓慢的 (其中金丝雀的时间一般会比后续批次更长，比如金丝雀 10 分钟，后续间隔 2 分钟)。
回退是发布的逆过程，将新版本流量从 LB 上摘除，清除新版本，发老版本，再将 LB 流量接入老版本。和发布过程一样，回退过程一般也比较慢的。
④优势和不足
优势：用户体验影响小，体验较平滑。
不足：
-- 发布和回退时间比较缓慢。
-- 发布工具比较复杂，LB 需要平滑的流量摘除和拉入能力。
总结：
① 蓝绿部署：准备两套环境，一套在线用，一套备用的新版本，在环境前做负载均衡，不影响老版本的基础上上线新版本。
②（金丝雀）灰度发布：是增量发布的一种类型。方法是保留部分老版本的同时，一点点发布新版本，进行测试和调整。K8S中使用的就是灰度发布。
③ 滚动发布：一般是取出一个或者多个服务器停止服务，执行更新，并重新将其投入使用。周而复始，直到集群中所有的实例都更新成新版本。
三、 devops 之 git
①： git 和 SVN 区别（重）
git是分布式的,svn是集中式的
git是每个历史版本都存储完整的文件,便于恢复,svn是存储差异文件
git可离线完成大部分操作,svn则不能
git有着更优雅的分支和合并实现
git有着更强的撤销修改和修改历史版本的能力
git速度更快,效率更高
②： git****版本控制的原理和流程
工作区 workspace：clone的代码或者开发编写代码文件所在的目录 ，通常是一个服务代码所在的目录名称 ,对应于<项目目录>
暂存区index ：用于存储在工作区中对代码进行修改后的文件所保存的地方，只有放入此区的文件才能被git进行管理,使用 git add添加,对应为<项目目录>/.git/index文件
本地仓库repo： 用于存储在工作区和暂存区中改过并提交的文件地方，使用 git commit 提交,对应于/<项目目录>/.git/
远程仓库 ：多个开发人员共同协作提交代码的仓库，即私有 gitlab 服务器或公有云github,gitee网站等
③： git 中文件的状态变化周期
untracked: 在工作目录下创建的新文件，这个时候本地git仓库不知道,不能对其进行版本跟踪管理
unmodified: 添加到暂存区的文件未修改,把文件从暂存区推动到本地仓库
modified: 已经添加到暂存区的文件,在本地工作区的文件被修改了 ,需要重新添加至暂存区
staged: 文件添加到了本地仓库里面的暂存区
④： Git 分支和标签
分支: 对文件的副本,可以实现多个不同用途的软件版本同时的演进,实现多个开发版本的隔离
分支在实际中有什么用呢？
假设你准备开发一个新功能，但是需要两周才能完成，第一周你写了50%的代码，如果立刻提交，由于代码还没写完，不完整的代码库会导致别人不能测试等工作。如果等代码全部写完再一次提交，又存在丢失每天进度的巨大风险。现在有了分支，就不用担心了。你创建了一个独立的分支，对其他人是透明的,没有影响,他们还继续在原来的分支上正常工作，而你在自己的分支上工作，想提交就提交，直到开发完毕后，再一次性合并到原来的分支上，这样既安全，又不影响别人工作。
tag: 给某个状态打个标签用于记录当前状态,相当于里程碑
tag是git版本库的一个标记，指向某个commit的指针。
tag主要用于发布版本的管理，一个版本发布之后，可以为git打上 v1.0.1,v1.0.2 ...这样的类似的标签。
tag跟branch有点相似，但是本质上和分工上是不同的：
tag 对应某次commit, 是一个点，是不可移动的。
branch 对应一系列commit，是很多点连成的一根线，有一个HEAD 指针，是可以依靠 HEAD 指针移动的。
所以，两者的区别决定了使用方式，改动代码用 branch ,不改动只查看用 tag。
tag 和 branch 的相互配合使用，有时候起到非常方便的效果
例如：已经发布了 v1.0 v2.0 v3.0 三个版本，这个时候，我突然想不改现有代码的前提下，在 v2.0 的基础上加个新功能，作为 v4.0 发布。就可以检出 v2.0 的代码作为一个 branch ，然后作为开发分支。
⑤. Git相关命令
git status
git log
git init
git checkout -b
git add
git rm --cache
git commit -m 版本名
git branch
git reset --hard HEAD^