阶段一：CI/CD基本概念与Git工具
DevOps
DevOps是一种实现Dev(开发)与Ops(运维)工作流有效联合的思想。
那么，我们为什么要了解什么是DevOps呢？因为我们下面所讲的课程内容最终的目的就是为了体现开发与运维有效结合方法，越是高级应用，越接近我们DevOps思想所阐述的做事方法。
首先我们先来了解一下软件开发层面从软件开发出现时起至今，都经历了些什么？
原始开发时代
这是软件开发的早期阶段，通常指20世纪50年代到70年代（Fortran，福传）。当时没有系统化的开发方法，程序员主要依赖个人经验，代码编写和调试过程较为混乱，缺乏标准化的流程。
瀑布开发时代
瀑布模型（Waterfall Model）出现在1970年代，是一种线性、顺序的开发方法。每个阶段（如需求分析、设计、编码、测试、维护）必须在前一个阶段完成后才能开始。虽然结构清晰，但缺乏灵活性，难以适应需求变更。
这就好比老式工厂流水线，做东西得一步一步来。先设计图纸，再买材料，然后开工，最后检查成品。每个步骤都得等上一步干完，特别规矩。但问题来了，要是图纸一开始画错了，后面全白干，还得从头来，费时又费力。
比如想要个圆桌结果画成了方桌，等成品出来才发现，前面买的材料、干的活全白费，还得推倒重来，费时又费力。
敏捷开发时代
敏捷开发（Agile）在2000年代兴起，以2001年的《敏捷宣言》为标志。它强调迭代开发、团队协作和快速响应变化。Scrum、Kanban等方法是敏捷的典型实践，适合动态的项目环境。
想象一个工厂不按老式流水线那套死板规矩来了，而是变成灵活的小作坊。你要做桌子，不一下子全干完，先跟客户说：“我先弄个小模型给你看。”你花一天做个桌腿儿拿去，客户说：“腿儿不错，但粗点更好。”你回去改，第二天再加个圆桌面给他瞧，他说：“对了，就这样！”你才把整张桌子做完。敏捷就是这样，分小块干，边做边问，随时调整，比瀑布那种画错图纸全白干强多了，重点是跟客户一起搞定东西，错了也能快改过来。
精益开发时代
精益开发（Lean Development）受到精益制造的启发，注重消除浪费、优化流程和快速交付价值。它与敏捷有重叠之处，但更聚焦于效率和客户价值的最大化。
现在工厂变精明了，你要做桌子，先跑去问客户：“你要啥样的？干嘛用？”客户说：“圆的，吃饭用，四人坐。”你算好尺寸，只买一米木头，不多不少，先做个小圆桌面试试，客户说：“大小行，腿儿再结实点。”你回去加固腿儿，还琢磨咋用最少材料干最好，优化每一步，最后桌子又快又好地做出来，没浪费啥。精益就这样，先想清楚再下手，尽量一次做对，比敏捷还省事儿，重点是不瞎折腾，只干有用的。
DevOps 运开时代
DevOps（Development + Operations）大约在2010年代流行起来，强调开发与运维的紧密协作，通过自动化、持续集成（CI）和持续交付/部署（CD）缩短开发周期，提升软件质量和部署速度。
想象你把工厂升级成了超级智能流水线，做桌子时设计（开发）和生产（运维）不再分开干，而是从头到尾一起上。你问客户要圆的四人桌，设计师画图，工人直接用自动化机器开工，图纸一改完，几分钟新桌子就出来，客户试用说“腿儿再粗点”，马上调整再生产，快得不行。工厂还有监控，桌子坏了立刻修，比瀑布那种“画错图纸全白干”、敏捷的“边做边改”、精益的“省着干”都牛，开发运维一条心，工具自动化全搞定，又快又稳还省心。
CI/CD
如果 Prometheus 属于 K8s 的“可观测性（Observability）”领域，
那么 Jenkins 和 GitLab 则属于“软件交付与运维自动化”领域，其核心是“CI/CD（持续集成/持续部署）。
下面我们具体介绍 CI/CD。
持续集成 Continuous Integration
相关概念
张三，李四 => 持续集成（每天至少把写好的代码集成到main主分支中一次） => 编译（maven打包）、发布、自动化测试。
CI是一种软件开发实践，即团队开发成员经常集成他们的工作，通常每个成员每天至少集成一次，也就意味着每天可能会发生多次集成。每次集成都通过自动化的构建（包括编译，发布，自动化测试）来验证，从而尽快地发现集成错误。
持续集成的核心目的是尽早发现并解决问题，减少风险与浪费，提升开发敏捷性、缩短周期，保障产品上线后用户体验。
传统开发模式在模块开发完成后才集成测试，导致早期引入的 bug 到后期才暴露，定位困难，甚至需调整底层架构，严重影响进度与周期。
持续集成能在集成测试前发现问题，保障软件质量、降低风险，助力团队应对变化；其报告可清晰呈现项目进度、已实现功能、自动化测试覆盖及代码质量，让团队掌握真实项目状态。
总结
第一步，持续集成（Continuous Integration，CI）
1 提：开发人员提交编写好的代码；
2 拉：触发构建，从代码仓库拉取开发写好的代码，代码可以是 gitlab 或者 svn 都可以；
3 编：编译代码，生成 Docker 镜像或者 Jar 包等，如果是镜像，还可以配置上传到镜像仓库；
4 测：自动化测试中，可以对代码做单元测试、集成测试；
5 查：质量检查阶段，会查看流水线生成结果，把成功/失败结果反馈给开发人员；
记住五字诀：提、拉、编、测、查。后面的交付和部署，也类似。
持续交付 Continuous Delivery
相关概念
持续交付是软件开发中，以小颗粒度需求短周期频繁提交，侧重集成后在类生产环境测试并及时反馈的过程。
目的
1. 开发过程的快速迭代，小步快跑，及时纠正偏离主线 2. 小颗粒度实现，避免颗粒度大，出现问题解决麻烦 3. 迅速反馈软件功能，避免方向性错误 4. 团队角色（含客户）协作密切，减少时间浪费
总结
第二步，持续交付（Continuous Delivery，CD）
1 拿包：从 CI 接收构建产物：如 Docker 镜像或二进制文件。
2 测包：部署到测试环境，进行更复杂的测试，比如性能压测、安全漏洞扫描；
持续部署 Continuous Deployment
相关概念
基于持续交付的基础上，把功能稳定，符合产品需求的版本有方法地部署至生产环境中。可以看作是持续交付的最后一环。
交付和部署的区别，就在于【测试环境】和【生产环境】。
总结
第三步，持续部署（Continuous Deployment，CD）
1 自动部署：通过工具（如 jenkins、Spinnaker）自动部署到生产环境；
2 监控状态：使用工具来监控系统状态，如 Zabbix、Prometheus、ELK；
3 失败回退：如果监测到故障或问题，可以在指定时间内，回退到上一版本，保证业务可用性；
思考
经常有运维同学，在面试时被问到，交付（Delivery）是做什么的？
提示
老师归纳知识点，目的是辅助记忆。面试回答时，适当发挥，不能仅回答六字：拿包、布包、测包。
持续交付，一般是指部署到测试环境，而非客户的环境当中。
持续，表示可能每天部署一次或多次，小步快跑的意思。
追问
在客户现场的交付过程当中，需要交付哪些材料（3个文档）？
这三个文档的大纲是什么？
持续发布 Continuous Release
相关概念
发布是周期性或不定期地对项目在部署后，进行整体软件版本的更新，例如，更新新功能或展示页面框架等。
目的
1. 产品的快速迭代，小步快跑 2. 适应市场变化 3. 匹配市场策略 4. 应对市场风险
总结
第四步，持续发布（Continuous Release，CR）
持续发布，是指周期性，或不定期地在项目部署后，进行整体软件版本的更新和发布。在这里，作为了解即可。
持续测试 Continuous Testing
相关概念
持续测试（Continuous Testing，简称CT）是贯穿着整个软件开发过程，验证程序员提交代码，检验合规性及降低bug，减少最终错误，实现敏捷及精益开发。
目的
1. 为了降低开发、部署、发布等可能出现的错误 2. 防止代码出错 3. 防止功能出错 4. 防止业务逻辑出错等
总结
1. CI 是 持续集成 Continuous Integration； 2. CD 相对是两个，是 Delivery 和 Deployment； 3. 比较持续交付和持续部署的区别：
无法复制加载中的内容
代码更新方法
蓝绿部署
海豚的秘密
大家都知道海豚是一种可爱的海洋动物。但又有多少人知道，海豚可以永远不睡觉。
是什么样的能力，使得海豚可以永远保持清醒呢？
依靠的是海豚大脑特殊的运作方式。
像人一样，海豚的大脑也分为左脑和右脑两个部分。
在海豚活跃的状态下，左脑和右脑都是清醒的：
当然，海豚也是血肉之躯，也是需要休息的。在海豚休息的状态下，其中一半大脑会进入睡眠，另一半大脑仍然保持清醒，以面对各种外界情况。
每隔两个小时，这种一半睡眠一半清醒的状态会进行交替，比如这一刻左脑睡眠右脑清醒，下一刻左脑清醒右脑睡眠。
这就是海豚永远不会真正睡觉的秘密。
蓝绿部署，英文名Blue Green Deployment，是一种可以保证系统在不间断提供服务的情况下上线代码的部署方式。
如何保证系统不间断提供服务呢？
蓝绿部署的模型中包含两个集群，就好比海豚的左脑和右脑。
在正常情况下（没有上线操作），集群A和集群B的代码版本是一致的，并且同时对外提供服务。
在有项目代码上线的时候，我们首先把一个集群（比如集群A）从负载列表中摘除，进行新版本的部署。集群B仍然继续提供服务。
当集群A升级完毕，我们把负载均衡重新指向集群A，再把集群B从负载列表中摘除，进行新版本的部署。集群A重新提供服务。
最后，当集群B也升级完成，我们把集群B也恢复到负载列表当中。这个时候，两个集群的版本都已经升级，并且对外的服务几乎没有间断过。
滚动更新
滚动更新，英文Rolling update，同样是一种可以保证系统在不间断提供服务的情况下上线代码的部署方式。
注：这种方式往往需要K8S支持
和蓝绿部署不同的是，滚动部署对外提供服务的版本并不是非此即彼，而是在更细的粒度下平滑完成版本的升级。
如何做到细粒度平滑升级版本呢？
滚动部署只需要一个集群，集群下的不同节点可以独立进行版本升级。比如在一个16节点的集群中，我们选择每次升级4个节点：
以此类推，最终所有的节点都升级了版本。
蓝绿部署与滚动更新对比
灰度发布（A/B测试、金丝雀部署）
灰度发布是指在黑与白之间，能够平滑过渡的一种发布方式。
AB test就是一种功能灰度发布方式，让一部分用户继续用A，一部分用户开始用B，如果用户对B没有什么反对意见，那么逐步扩大范围，把所有用户都迁移到B上面来。
灰度发布可以保证整体系统的稳定，在初始灰度的时候就可以发现、调整问题，以保证其影响度，而我们平常所说的金丝雀部署也就是灰度发布的一种方式。
灰度发布/金丝雀部署步骤：
1. 准备好部署各个阶段的工件，包括：构建工件，测试脚本，配置文件和部署清单文件。 2. 从负载均衡列表中移除掉“金丝雀”服务器。 3. 升级“金丝雀”应用（排掉原有流量并进行部署）。 4. 对应用进行自动化测试。 5. 将“金丝雀”服务器重新添加到负载均衡列表中（连通性和健康检查）。 6. 如果“金丝雀”在线使用测试成功，升级剩余的其他服务器。（否则就回滚）
除此之外灰度发布还可以设置路由权重，动态调整不同的权重来进行新老版本的验证。
17世纪，英国矿井工人发现，金丝雀对瓦斯这种气体十分敏感。空气中哪怕有极其微量的瓦斯，金丝雀也会停止歌唱；而当瓦斯含量超过一定限度时，虽然鲁钝的人类毫无察觉，金丝雀却早已毒发身亡。当时在采矿设备相对简陋的条件下，工人们每次下井都会带上一只金丝雀作为“瓦斯检测指标”，以便在危险状况下紧急撤离。
[扩展] 面试题
1、怎么保证在服务不中断的情况下，进行版本升级？
答：这道题，其实就是问代码更新方法。但不是八股文问题。回答的时候，要把握蓝绿部署，滚动更新来回答。再结合路由权重，限流操作，就可以。
版本控制
版本记录
centos7.5, centos7.6,centos7.7,centos7.9这些属于操作系统的版本。
nginx-1.10,nginx1.14这些属于软件的版本。
一个配置文件或一个代码文件被多次修改,也会有对应的版本,比如v1.0,v2.0,v3.0
版本控制
版本控制软件提供完备的版本管理功能，用于存储、追踪目录（文件夹）和文件的修改历史，是软件开发者的必备工具，是软件公司的基础设施。版本控制软件的最高目标，是支持软件公司的配置管理活动，追踪多个版本的开发和维护活动，及时发布软件。
常见的版本控制系统及比较
cvs,svn,git都是版本控制系统
cvs和svn都是集中式版本控制系统,而git是分布式版本控制系统。
比较
- 集中式版本控制系统必须联网才能工作，如果在局域网内还好，带宽够大，速度够快，可如果在互联网上，遇到网速慢的话，呵呵。分布式版本控制系统可以不连网工作, 因为版本库就在你自己的电脑上。
- 集中式版本控制系统如果中央服务器挂了,就完蛋了。分布式版本控制系统可以没有中央服务器，每个人的电脑上都是一个完整的版本库，可靠性高。分布式版本控制系统也可以有一台充当“中央服务器”的电脑，但这个服务器的作用仅仅是用来方便“交换”大家的修改，没有它大家也一样干活，只是交换修改不方便而已。
代码托管 Git
Git 概述
Git诞生：分布式项目管理工具，目前整个行业内最流行最受欢迎的项目版本管理工具
开发者：Linus Torvalds
Linux的创始人
Linux诞生以后，全球很多开发者开发了很多个版本的Linux，提交给Linus Torvalds
Linus Torvalds 将优秀的代码集成在Linux内核中，手动管理所有的代码
Linus Torvalds 不喜欢传统的免费CVS等工具，因为这些工具不好用，好用的都收费
Linus Torvalds 选择了一个商业化的工具，达成协议可以免费使用
于是团队中的一个哥们有个想法：能不能破解这个东西？
被发现了：Linus Torvalds 保证不再破解
两周以后，Linus Torvalds 自己用C语言开发了Git，使用了类似于Linux的管理方式
Linus Torvalds ：将Linux的版本控制切换到Git上
Git的开发汲取了其他的版本控制工具的优点，避免了缺点
用git，原生的方式就相当于写Linux命令
Git 安装
官网: https://git-scm.com/
Debian 戴比安
git安装
[root@vm1 ~]# yum install git
[root@vm1 ~]# git --version
git version 2.43.5命令作用：
- 使用
yum包管理器执行install操作，对软件包进行安装、更新、删除或查询。
执行结果：
- 成功后软件包会按指定动作完成安装、更新、删除或查询；失败时检查仓库、网络和权限。
关键参数：
注意事项：
查看参数帮助 git的操作可以说只需要git一条命令加参数即可
因为git是分布式版本控制系统,不同的人提交代码需要区分,所以每个人都要设置一个身份标识。如果不设置的话谁会知道你这个开发者是张三，李四，还是王五呢?
user.name=daniel
user.email=daniel@itcast.cn
color.ui=true仓库分为本地仓库与远程仓库
创建本地仓库的步骤:
**关键参数：**
**注意事项：**代码文件需要commit提交后才能纳入版本控制。
# # # #
关键参数：
注意事项：
提交1.py
说明
**注意事项：**
**注意事项：**
注意事项：
如果开发者状态不好,今天写的代码一团乱,想吃后悔药,git也提供了撤销的方法。
**注意事项：**
1.py
说明下面命令恢复报错
分支可以看作为平行空间
**注意事项：**注意事项：
4.py | 1 +
**注意事项：**
有些复杂的情况会造成冲突，这个时候git就不能帮我们自动的合并分支。我们就要手动处理冲突。
冲突测试注意事项：
注意事项：
git使用<<<<<<<<<,=========,>>>>>>>>符号分割冲突的内容，手动删除这些符号，并修改成你想要的内容
解决冲突前: ======= 冲突测试
解决冲突后: 冲突解决
**注意事项：**
如果你不小心删除了一个分支，还是可以恢复的。
说明
Windows上安装git
