1 从敏捷开发到CI/CD
1.1 什么是敏捷开发
敏捷开发（Agile Development） 是一种软件开发方法论，核心思想是：
快速迭代、小步快跑、持续反馈、快速响应变化。
1.2 核心理念
迭代式开发：把项目拆分成多个短周期（通常 1～2 周）的迭代，每次迭代都产出一个可运行的版本。
持续交付价值：每次迭代都要能交付能用的功能，尽早让用户看到结果。
快速响应变化：如果用户需求变了，团队能快速调整方向。
团队协作：强调跨职能团队的紧密协作（开发、测试、运维、产品、设计）。
1.3 举例说明
传统开发像是盖房子：
先打地基 → 起框架 → 装修 → 交付，一次性交房。
敏捷开发像是造车：
先造一个能滑动的滑板 → 再加个把手变成滑板车 → 再加引擎变摩托 → 最后变汽车。
每次都能“跑起来”，并且随时根据反馈调整方向。
2 传统开发对比敏捷开发
3 为什么需要CI/CD
CI/CD 是敏捷开发落地的“自动化基础设施”，它的全称是：
CI（持续集成，Continuous Integration）
CD（持续交付/部署，Continuous Delivery / Continuous Deployment）
3.1 CI：持续集成
开发者频繁地（每天多次）把代码合并到主分支，并通过自动化流程进行构建、测试和质量检查。
目的
尽早发现集成问题
保证代码主分支始终可构建、可运行
减少 “集成地狱”（最后才合并代码时各种冲突）
举例
每次提交代码后，CI 流水线自动执行：
编译代码
运行单元测试
扫描代码质量（如 SonarQube）
构建镜像（Docker）
推送到镜像仓库（Harbor）
3.2 CD：持续交付 / 部署
在 CI 的基础上，自动化地：
把通过测试的构建包自动部署到测试环境、预发布环境，甚至生产环境。
持续交付（Continuous Delivery）
自动化部署到测试/预发布环境，但上线前需要人工确认。
持续部署（Continuous Deployment）
连生产环境都自动化发布，无需人工干预。
举例
CI 构建完镜像后 → CD 自动部署到 Kubernetes → ArgoCD 监控 Git 仓库变更 → 自动更新生产服务。
4 CICD 优点
4.1 快速交付
CI/CD 自动化流程可以使软件交付过程更快、更频繁，减少了手动操作和人工干预的时间。这样可以更快地将新功能、修复和改进的代码交付给用户，满足市场需求并保持竞争优势。
提高质量
持续集成通过频繁地集成和构建代码，并进行自动化测试和静态代码分析，有助于发现和解决问题。通过尽早发现和修复缺陷，可以提高软件的质量和稳定性。
自动化部署
持续交付将部署过程自动化，从而减少了手动部署的错误和风险。通过自动化部署流程，可以确保软件在不同环境中的一致性，并减少了部署时间和工作量。
可靠性和可重复性
CI/CD 强调自动化和标准化的流程，使软件交付过程变得可靠和可重复。每次构建、测试和部署都是基于相同的流程和环境，减少了人为因素的影响，提高了软件交付的一致性和可靠性。
团队协作与反馈
CI/CD 促进了团队成员之间的协作和沟通。通过频繁地集成和交付，团队成员可以及时了解彼此的工作进展和变更，减少代码冲突和集成问题，并能够更好地合作解决出现的问题。
可追溯性和回滚能力
由于 CI/CD 自动化流程的记录和版本控制，可以轻松追踪每个构建和部署的结果。这样，在出现问题时可以快速定位和回滚到之前的可用版本，减少了故障修复时间和影响范围。总而言之，CI/CD 提供了一种高效、可靠和可持续的软件交付方法。它可以加速软件开发和交付的速度，提高软件质量和可靠性，并促进团队之间的协作和反馈。通过使用 CI/CD，组织可以更好地适应市场需求，降低软件交付的风险，并实现持续创新和改进。
5 从CI/CD到DevOps
5.1 DevOps 是理念和文化
DevOps（Development + Operations） 是一种理念、文化和一整套实践方法，
目标是让 “开发（Dev）” 和 “运维（Ops）” 紧密合作，从而实现：
更快地交付软件（高频发布）
更稳定地运行系统（高可用）
更及时地获取反馈（持续改进）
核心目标：持续交付价值，让软件开发 → 部署 → 运维成为一个流畅的闭环。
CI/CD（持续集成 / 持续交付 / 持续部署） 是 DevOps 理念的技术支撑与自动化实践。它可使得：
代码提交 → 自动构建 → 自动测试 → 自动部署
全程无人干预，标准化、自动化、可回溯。
5.3 两者对比
6 从DevOps到GitOps
6.1 DevOps 的挑战
6.2 GitOps 前提
6.2.1 不可变基础设施
不可变基础设施（Immutable Infrastructure）：不可变基础设施是由Chad Fowler于 2013 年提出的一个构想：在这种模式中任何基础设施的实例一旦创建之后便成为一种只读状态，不可对其进行任何更改。如果需要修改或升级某些实例，唯一的方式就是创建一批新的实例以替换。 传统可变基础设施是将应用打包好部署在不同的机器上，需要确保环境的统一，并通过修改、补丁的方式持续更新应用，随着时间的推移很难再确保所有的机器处于相同的状态；而不可变基础架构，是将整个机器环境打包成一个单一的不可变单元，这个单元包含了整个环境和应用本身，以解决传统可变基础架构的问题。
6.2.2 基础架构即代码
基础架构即代码（IaC）：使用代码（而非手动流程）来定义基础设施，研发人员可以像对待应用软件一样对待基础设施，例如：
可以创建包含基础架构规范的声明式配置文件，从而便于编辑和分发配置。
可以确保每次配置的环境都完全相同。
可以进行版本控制，所有的变更都会被记录下来，方便溯源。
可以将基础设施划分为若干个模块化组件，并通过自动化以不同的方式进行组合。
通过使用容器技术可以实现基础设施的不变性，而Kubernetes的声明性容器编排可以实现基础架构即代码。GitOps基于不可变基础设施和IaC，结合Git进行应用系统整个配置文件集版本控制。
目前主流的 IaC 工具是混合云编排工具Terraform。
6.3 什么是GitOps
GitOps = IaC + Git + CI/CD，即基于 IaC 的版本化 CI/CD。它的核心是使用 Git 仓库来管理基础设施和应用的配置，并且以 Git 仓库作为基础设施和应用的单一事实来源，你从其他地方修改配置（比如手动改线上配置）一概不予通过。
在 GitOps 实践中，我们需要将软件设施定义在 Git 仓库中进行管理。其中的软件设施，包括 IaaS、Kubernetes 这样的基础设施，也包括应用本身。每个人都可以通过提交 Pull Request 来修改软件设施，然后通过自动化的程序执行这种修改。借助于 GitOps，如果集群的实际状态与 Git 仓库中定义的期望状态不匹配，Kubernetes reconcilers 会根据期望状态来调整当前的状态，最终使实际状态符合期望状态。
这种方式使得每个人都可以专注于开发新的功能，而不用陷入繁琐的安装、变更、迁移等运维工作。同时，整个过程具有完整的操作记录和权限审批管理。
6
6.5 GitOps 的设计哲学
想要使用 GitOps 来管理你的基础设施和应用，需要践行以下几个原则：
6.5.1 声明式
必须通过声明式来描述系统的期望状态。例如 Kubernetes，众多现代云原生工具都是声明式的，Kubernetes 只是其中的一种。
6.5.2 版本控制/不可变
因为所有的状态声明都存储在 Git 仓库中，并且把 Git 仓库作为单一事实来源，那么所有的操作都是从 Git 仓库里驱动的，而且保留了完整的版本历史，方便回滚。有了 Git 优秀的安全保障，也可以使用 SSH 密钥来签署 commits，对代码的作者和出处实施强有力的安全保障。
6.5.3 自动应用变更
Git 仓库中声明的期望状态发生了任何变更，都可以立即应用到系统中，而且不需要安装配置额外工具（比如 kubectl），也不需要配置 Kubernetes 的认证授权。
6.5.4 持续的 Reconciliation
Reconciliation 其实最早是 Kubernetes 里的一个概念，表示的是确保系统的实际状态与期望状态一致的过程。具体的实现方式是在目标环境中安装一个 agent，一旦实际状态与期望状态不匹配，agent 就会进行自动修复。这里的修复比 Kubernetes 的故障自愈更高级，即使是手动修改了集群的编排清单，集群也会被恢复到 Git 仓库中的清单所描述的状态。
6.6 GitOps 的工作流
团队中的任何一个成员都可以 Fork 仓库对配置进行更改，然后提交 Pull Request。
接下来会运行 CI 流水线，一般会做这么几件事情：验证配置文件、执行自动化测试、检测代码的复杂性、构建 OCI 镜像、将镜像推送到镜像仓库等等。
CI 流水线运行完成后，团队中拥有合并代码权限的人将会将这个 Pull Request 合并到主分支中 。一般拥有这个权限的都是研发人员、安全专家或者高级运维工程师。
运行 CD 流水线，将变更应用到目标系统中（比如 Kubernetes 集群或者 AWS） 。
整个过程完全自动化且透明，通过多人协作和自动化测试来保证了基础设施声明配置的健壮性。而传统的模式是其中一个工程师在自己的电脑上操作这一切，其他人不知道发生了什么，也无法对其操作进行 Review。
6.7 GitOps的工作模式
6.7.1 Push 模式
目前大多数 CI/CD 工具都使用基于 Push 的部署模式，例如 Jenkins、CircleCI 等。这种模式一般都会在 CI 流水线运行完成后执行一个命令（比如 kubectl）将应用部署到目标环境中。
这种 CD 模式的缺陷很明显：
需要安装配置额外工具（比如 kubectl）；
需要 Kubernetes 对其进行授权；
需要云平台授权；
无法感知部署状态。也就无法感知期望状态与实际状态的偏差，需要借助额外的方案来保障一致性。
Kubernetes 集群或者云平台对 CI 系统的授权凭证在集群或云平台的信任域之外，不受集群或云平台的安全策略保护，因此 CI 系统很容易被当成非法攻击的载体。
6.7.2 Pull 模式
Pull 模式会在目标环境中安装一个 Agent，例如在 Kubernetes 集群中就靠 Operator 来充当这个 Agent。Operator 会周期性地监控目标环境的实际状态，并与 Git 仓库中的期望状态进行比较，如果实际状态不符合期望状态，Operator 就会更新基础设施的实际状态以匹配期望状态。 只有 Git 的变更可以作为期望状态的唯一来源，除此之外，任何人都不可以对集群进行任何更改，即使你修改了，也会被 Operator 还原为期望状态，这也就是传说中的不可变基础设施。
6.8 GitOps 的优势
一般 GitOps 首选的都是基于 Pull 的部署模式，因为这种模式有很多不可替代的优势。
6.8.1 更强大的安全保障
使用 GitOps 不需要任何 Kubernetes 或者云平台的凭证来执行部署，Kubernetes 集群内的 Argo CD 或者 Flux CD 只需要访问 Git 仓库，并通过 Pull 模式来更新即可。
另一方面，Git 由用于跟踪和管理代码变更的强大密码学支持，拥有对变更进行签名以证明作者身份和来源的能力，这是保障集群安全的关键。
6.8.2 Git 作为事实的唯一真实来源
因为所有的应用包括基础设施的声明式配置都保存在 Git 中，并把 Git 作为应用系统的唯一事实来源，因此可以利用 Git 的强大功能操作所有东西，例如版本控制、历史记录、审计和回滚等等，无需使用 kubectl 这样的工具来操作。
6.8.3 提高生产力
Git 也是开发人员非常熟悉的工具，通过 Git 不断迭代，可以提高生产率，加快开发和部署速度，更快地推出新产品，同时提高系统的稳定性和可靠性。
6.8.4 更容易合规的审计
使用 GitOps 的基础设施可以像任何软件项目一样使用 Git 来管理，所以同样可以对其进行质量审计。当有人需要对基础设施进行更改时，会创建一个 Pull Request，等相关人员对其进行 Code Review 之后，更改才可以应用到系统中。
评论区