现代信息社会，快速稳定的交付客户所需的应用是企业成功的关键，随着时代发展，开发现代应用程序与过去的方法不同，许多团队开始探索使用DevOps来加速实现自己的业务价值。
DevOps：加速价值交付
DevOps 描述了加快流程的方法，通过这些流程，可以快速将一个想法（如新的软件功能、增强请求或错误修复）实现从开发到部署，并最终为用户提供价值。这些方法要求开发团队和运维团队保持持续沟通，并用同理心来处理他们的工作。双方一起密切合作，在不牺牲可靠性的情况下加快软件构建、测试和发布。
DevOps是“development”和“operations”的混搭，但它不仅代表了开发和运维，更代表了一组想法和实践，包括安全性、协作工作方式、数据分析和许多其他内容。同时DevOps 也依赖于开源原则和透明、敏捷的工作方式相一致的协作文化。
DevOps 加快了创意从开发到部署的过程。DevOps 的核心依赖于在应用的整个生命周期中自动执行日常操作任务和标准化环境。容器可以提供标准化的环境，大规模容器需要一个平台来管理它们，并结合自动化能力支持。
引入DevOps改变的不仅仅是工作方式，所做的工作也不可避免地会改变。DevOps 不仅仅是加快创建单体软件，而是创建更适合这种持续交付节奏的新型软件。这就是为什么 DevOps 团队通常会使用微服务架构构建软件并将这些服务与 API 连接在一起的原因。团队通过专注于创建较小的功能来更快地交付。
CI/CD：通过自动化加速交付
CI/CD（Continuous integration/continuous deployment）是一种通过将自动化引入应用开发阶段来频繁向客户交付应用的方法。CI/CD 的主要概念是持续集成、持续交付和持续部署。
CI/CD 是 DevOps 方法的支柱，它将开发人员和运维团队聚集在一起部署软件，让代码发布的速度成为竞争优势。
CI/CD 在整个应用程序生命周期（从集成和测试阶段到交付和部署）中应用自动化，以快速生成经过测试和验证的应用程序。它包含两个不同但相关的功能：
- 持续集成 （CI） 帮助开发人员快速验证功能，并更频繁地将其代码更改合并回共享分支。通过自动构建应用程序并运行不同级别的自动化测试（通常是单元测试和集成测试）来验证合并的代码更改，以确保更改正常工作。如果测试发现新代码和现有代码之间存在冲突，CI 可以更轻松、更快速地修复这些错误。
- 持续部署 （CD） 自动执行将应用程序发布到生产环境的过程。在生产前的开发管道阶段，很少有手动干预，因此CD严重依赖精心设计的测试自动化。因此，如果开发人员对云应用程序的更改通过所有自动化测试，则它可以在编写云应用程序后的几分钟内上线。CD 使持续接收和合并用户反馈变得更加容易。
CI/CD 允许以较小的部分发布对应用程序的更改，从而使应用程序部署更加可靠。同时也可以将 CI/CD 应用于组织内的许多组件和资产，包括应用程序、平台、基础结构、网络和自动化代码。
基础设施即代码IaC
基础设施即代码（Infrastructure as Code, IaC）是实施 DevOps 实践和持续集成/持续交付 （CI/CD） 的重要组成部分。IaC 可以标准化开发与运维团队的交互方式，并确保基础设施的一致性，释放开发与运维的大部分准备和协调工作。
配置基础设施历来是一个耗时且成本高昂的手动过程。现在，基础设施的管理已经从数据中心的物理硬件（尽管这仍然是您组织的组件）转向虚拟化、容器和云计算。借助云计算，基础设施组件的数量不断增长，每天都有更多的应用程序发布到生产环境，并且基础设施需要能够频繁地启动、扩展和关闭。如果没有 IaC ，管理当今基础设施的规模变得越来越困难。
与此同时，CI/CD 依赖于从集成和测试到交付和部署的整个应用程序生命周期的持续自动化和持续监视。为了使环境自动化，需要保持一致。当开发团队以一种方式部署应用程序或配置环境，而运维团队以另一种方式部署和配置环境时，自动化应用程序部署不起作用。通过 DevOps 方法协调开发和运营团队可以减少错误、手动部署和不一致。IaC 可帮助协调开发和运维，两个团队可以使用相同的应用程序部署描述，从而支持 DevOps 实践。
DevOps 最佳实践也适用于 IaC 中的基础设施。基于IaC，基础设施可以实现与应用程序在软件开发期间相同的 CI/CD 管道，对基础设施代码应用相同的测试和版本控制。这引出了GitOps。
GitOps
GitOps 可以被视为基础设施即代码 （IaC） 的演变，并使用 Git 作为基础设施配置的版本控制系统。IaC 通常通过定义系统的所需状态并跟踪系统的实际状态来遵循声明性基础设施的管理方法。与 IaC 一样，GitOps 要求以声明方式描述系统的所需状态。通过使用声明性工具，可以在 Git 中对所有配置文件和源代码进行版本控制。
GitOps 提供：
- 应用程序开发的标准工作流程
- 提高了预先设置应用程序要求的安全性
- 通过 Git 提高可见性和版本控制的可靠性
- 跨任何集群、任何云和任何本地环境的一致性
通过使用开发人员熟悉的基于 Git 的相同工作流，GitOps 扩展了从应用程序开发到部署、应用程序生命周期管理和基础设施配置的现有流程。整个应用程序生命周期中的每个更改都会在 Git 存储库中进行跟踪，并且是可审核的。通过 Git 进行更改意味着开发人员最终可以做他们想做的事：按照自己的节奏编写代码，而无需等待运维团队分配或批准资源。
对于运维团队而言，变更可见性意味着能够快速跟踪和重现问题，从而提高整体安全性。借助最新的审计跟踪，组织可以降低不必要的更改的风险，并在投入生产之前对其进行更正。
GitOps 方法的目标和优势显而易见。通过将所需基础设施和应用程序配置的定义存储在 Git 存储库中，团队将拥有在结构化且安全的存储部署应用程序所需的一切。如果出于灾难恢复或复原能力的原因需要将应用程序重新部署到新位置，则可以轻松自信地执行此操作。此外，GitOps 模型将帮助组织在生产过程中通过各个测试阶段推进应用程序。此过程需要将应用程序部署到不同的群集或群集中的不同命名空间，而 GitOps 模型确保可以完全、可靠且自信地完成此操作。
基础设施和应用程序这两个域之间有明显的区别，组织的不同团队负责每个领域。基础设施配置负责 Kubernetes 平台的定义和交付，包括计算节点、基于角色的访问控制、治理策略以及创建应用程序可以运行的平台的许多其他属性。应用程序可以分段为编译为容器映像中的可执行文件的源代码组件，以及在特定环境中配置容器映像的 Kubernetes 资源。
GitOps 工作流
若要开始使用 GitOps，需要能够以声明方式管理的基础设施。正因为如此，GitOps 通常被用作 Kubernetes 和云原生应用程序开发的模型，并且与 Kubernetes 实现持续部署。
CI/CD 管道通常由外部事件触发，例如将代码推送到存储库。在 GitOps 工作流中，使用拉取请求（pull request）进行更改，这些请求修改 Git 存储库中的状态。批准并合并更改后，它们将自动应用于实时基础设施。开发人员可以继续使用其标准工作流和 CI/CD。
当将 GitOps 与 Kubernetes 一起使用时，自动化同步的实现通常是 Kubernetes Operator。Operator 将存储库中的所需状态与已部署基础设施的实际状态进行比较。每当发现实际状态与存储库中存在的状态之间存在差异时，将更新基础设施。还可以监视容器映像存储库，并以相同的方式进行更新以部署新映像。
GitOps 工作流可以提高生产力以及开发和部署的速度，同时提高系统的稳定性和可靠性。
总结
GitOps 和 DevOps 有一些相同的原则和目标。DevOps 是关于文化变革的，并为开发团队和运维团队提供了一种协同工作的方式。GitOps 提供了采用 DevOps 实践（如协作、CI/CD 和版本控制）的工具和框架，并将其应用于基础设施自动化和应用程序部署。开发人员可以在他们的代码库中工作，而 Operator 可以将其他必要的部分放置到位。在实践中，逐渐形成了：
- 以DevOps理念为指导
- 使用微服务开发应用
- 基于容器化标准交付
- 基于声明式的基础设施部署
- 用git作为单一事实来源
- 基于自动化的CI/CD
最终演变为基于git的全流程CI/CD工作流框架，也即GitOps，实现敏捷价值交付。
