打造企业级自动化运维平台系列（二）：DevOps、CI、CD、CT 详解

戳下方名片，关注并星标！回复“1024”获取2TB学习资源！前面介绍了云原生架构的核心技术等相关的知识点，今天我将详细的为大家介绍 DevOps、CI、CD、CT 相关知识，希望大家能够从中收获多多！如有帮助，请点在看、转发分享朋友圈支持一波！！！DevOps 出现之前传统的软件交付流程一个软件从零开始到最终交付，大概包括以下几个阶段：规划、编码、构建、测试、发布、部署和维护，基于这些阶段，我们的

民工哥

424人浏览 · 2024-01-11 08:51:52

民工哥 · 2024-01-11 08:51:52 发布

戳下方名片，关注并星标！

回复“1024”获取2TB学习资源！

前面介绍了云原生架构的核心技术等相关的知识点，今天我将详细的为大家介绍 DevOps、CI、CD、CT 相关知识，希望大家能够从中收获多多！如有帮助，请点在看、转发分享朋友圈支持一波！！！

DevOps 出现之前

传统的软件交付流程

一个软件从零开始到最终交付，大概包括以下几个阶段：规划、编码、构建、测试、发布、部署和维护，基于这些阶段，我们的软件交付模型大致经历了以下几个阶段。更多关于构建企业自动化运维平台系列的学习文章，请参阅：企业级自动化运维平台，本系列持续更新中。

瀑布式流程

前期需求确立之后，软件开发人员花费数周和数月编写代码，把所有需求一次性开发完，然后将代码交给 QA（质量保障）团队进行测试，然后将最终的发布版交给运维团队去部署。瀑布模型，简单来说，就是等一个阶段所有工作完成之后，再进入下一个阶段。这种模式的问题也很明显，产品迭代周期长，灵活性差。一个周期动辄几周几个月，适应不了当下产品需要快速迭代的场景。

敏捷开发

任务由大拆小，开发、测试协同工作，注重开发敏捷，不重视交付敏捷。

DevOps

开发、测试、运维协同工作，持续开发+持续交付。我们是否可以认为 DevOps = 提倡开发、测试、运维协同工作来实现持续开发、持续交付的一种软件交付模式？

大家想一下为什么最初的开发模式没有直接进入 DevOps 的时代？

原因是：沟通成本。

各角色人员去沟通协作的时候都是手动去做，交流靠嘴，靠人去指挥，很显然会出大问题。所以说不能认为 DevOps 就是一种交付模式，因为解决不了沟通协作成本，这种模式就不具备可落地性。

那 DevOps 时代如何解决角色之间的成本问题？DevOps 的核心就是自动化。自动化的能力靠什么来支撑，工具和技术。更多关于构建企业自动化运维平台系列的学习文章，请参阅：企业级自动化运维平台，本系列持续更新中。

到底什么是 DevOps 呢?

DevOps并不是凭空创造出来的一个概念，DevOps是Development和Operations的组合，是一种方法论，是一组过程、方法与系统的统称，用于促进应用开发、应用运维和质量保障（QA）部门之间的沟通、协作与整合。以期打破传统开发和运营之间的壁垒和鸿沟。它也是有着历史的发展过程的。

简而言之，DevOps是继软件开发的瀑布模型、敏捷模型后的第三种软件开发的方法论，可以理解为：

第一阶段：瀑布模型
第二阶段：敏捷模型
第三阶段：DevOps

在瀑布模型中，大家分工合作，开发、测试、部署、运维，每一部分都有专门的团队负责，开发完成后进入测试环节，测试完成后进去部署环节，部署完成后进入运维环节，每个环节都是独立的，有着独立的开发团队、测试团队、部署团队、运维团队。

瀑布模型的弱点在于，软件上线周期长，对于新需求的反映速度慢。因而，在瀑布模型的基础上，衍生出了敏捷开发，强调“开发测试”一起搞，小步快走完成开发任务，但仍然有独立的部署团队和运维团队。

DevOps是敏捷模型的进一步升级，为了进一步加快软件的上线速度，更快地对客户需求做出反应，强调“开发测试部署运维”全部一起搞定。

这也就是DevOps缩写的含义，也即Development and Operation, 开发和运维。

总结起来，采用DevOps这种方法论，主要就是想在软件开发过程中提升以下几点：

更专注于用户的需求
更快的上线速度
更自动化流程
更稳定的运行时长
为了实现这一目标，有着一些列辅助DevOps的工具和方法论，例如包括软件架构上的微服务设计Microservices、云原生的部署方案K8S、持续集成持续交付CICD等。

DevOps和Agile之间的根本区别吗？

答：尽管DevOps与敏捷方法（这是最流行的SDLC方法之一）有一些相似之处，但两者都是软件开发的根本不同的方法。以下是两者之间的各种基本差异：

敏捷方法–敏捷方法仅适用于敏捷开发，而敏捷方法则适用于DevOps中的开发和运营。
实践和流程–敏捷涉及敏捷Scrum和敏捷看板等实践，而DevOps涉及CD（持续交付），CI（持续集成）和CT（持续测试）等流程。
优先级–敏捷优先考虑及时性，而DevOps优先考虑及时性和质量。
发布周期–DevOps提供较小的发布周期并提供即时反馈，而Agile仅提供较小的发布周期而没有立即反馈。
反馈源–敏捷依赖于客户的反馈，而DevOps涉及到自身（监控工具）的反馈。
工作范围–对于敏捷，工作范围仅是敏捷，而对于DevOps，这是敏捷和对自动化的需求。

DevOps 软件开发流程

整体的软件开发流程包括：

PLAN：开发团队根据客户的目标制定开发计划
CODE：根据PLAN开始编码过程，需要将不同版本的代码存储在一个库中。
BUILD：编码完成后，需要将代码构建并且运行。
TEST：成功构建项目后，需要测试代码是否存在BUG或错误。
DEPLOY：代码经过手动测试和自动化测试后，认定代码已经准备好部署并且交给运维团队。
OPERATE：运维团队将代码部署到生产环境中。
MONITOR：项目部署上线后，需要持续的监控产品。
INTEGRATE：然后将监控阶段收到的反馈发送回PLAN阶段，整体反复的流程就是DevOps的核心，即持续集成、持续部署。

总的来说就是：

1.Code阶段（编码）：Git+GitLab
2.Build阶段（构建）：Maven或Gradle
3.Operate（运行）：Docker
4.Integrate（集成）：Jenkins
- CI/CD(持续集成)：操作Jenkins，编写对应脚本文件
- Code review（代码质量检测）：Jenkins集成Sonar Qube
- 自定义镜像：Harbor
- Jenkins流水线操作
- WebHook：通知操作，如：钉钉机器人通知
5.K8S编排：更加方便我们管理容器

设计上的妥协与变通

通过上面的介绍可以了解到，实施DevOps，不仅仅要在软件开发理念上改变，也要在组织架构上发生改变，要打破开发测试部署运维的组织边界和职能边界，同时为了完成这一目标，软件的架构设计也会发生变动，即从之前的“单体架构monolithic architecture”转变成“微服务架构Microservices”。

云原生为什么要使用微服务架构，让我们首先对比下两种架构的优势与劣势。更多关于构建企业自动化运维平台系列的学习文章，请参阅：企业级自动化运维平台，本系列持续更新中。

对于传统的单体架构：对于微服务架构：可见，微服务架构虽然灵活，但微服务也不是万灵丹，微服务架构带来系统敏捷性的同时，也有着很多的妥协和挑战。例如为了微服务间的解耦，可能需要创建更多冗余的服务或数据，这与之前软件设计中的do not repeat yourself是完全相反的思路，这种设计也为数据的最终一致性带来了不小挑战。

可以说，实施DevOps方法论和微服务架构目前也仍然是在不断试错、不断摸索的过程中。

有一点需要注意的是，使用微服务架构，构建云原生应用程序的初衷并非是“降低运营成本”，因为随着微服务数量的增加，其所消耗的基础设施成本也是指数级增长的。使用微服务架构的初衷是获得更高的敏捷性，获得更快的部署速度，更快的软件迭代周期。

复杂的DevOps工具链

以下是一些使用最广泛的DevOps工具的列表：

Ansible 配置管理和应用程序部署工具
Chef 配置管理和应用程序部署工具
Docker 容器化工具
Git 版本控制系统（VCS）工具
Jenkins 持续集成（CI）工具
Jira 敏捷的团队协作工具
Prometheus 监控工具
Puppet 配置管理和应用程序部署工具
硒连续测试（CT）工具
Maven 自动化构建工具
NuGet .Net 包管理器
JUnit 用于 Java 的单元测试框架
Kubernetes 用于编配 Docker 容器的系统
ELK 日志收集分析平台
Zipkin 分布式跟踪系统

CI/CD/CT

CI

CI的英文名称是Continuous Integration，中文翻译为：持续集成。CI中，开发人员将会频繁地向主干提交代码，这些新提交的代码在最终合并到主干前，需要经过编译和自动化测试流进行验证。

持续集成（CI）是在源代码变更后自动检测、拉取、构建和（在大多数情况下）进行单元测试的过程。持续集成的目标是快速确保开发人员新提交的变更是好的，并且适合在代码库中进一步使用。CI的流程执行和理论实践让我们可以确定新代码和原有代码能否正确地集成在一起。

CD

CD可对应多个英文名称，持续交付Continuous Delivery和持续部署Continuous Deployment ，以下分别介绍。

持续交付

完成 CI 中构建及单元测试和集成测试的自动化流程后，持续交付可自动将已验证的代码发布到存储库。为了实现高效的持续交付流程，务必要确保 CI 已内置于开发管道。持续交付的目标是拥有一个可随时部署到生产环境的代码库。在持续交付中，每个阶段（从代码更改的合并，到生产就绪型构建版本的交付）都涉及测试自动化和代码发布自动化。在流程结束时，运维团队可以快速、轻松地将应用部署到生产环境中或发布给最终使用的用户。

持续部署

对于一个成熟的CI/CD管道（Pipeline）来说，最后的阶段是持续部署。作为持续交付——自动将生产就绪型构建版本发布到代码存储库——的延伸，持续部署可以自动将应用发布到生产环境。持续部署意味着所有的变更都会被自动部署到生产环境中。持续交付意味着所有的变更都可以被部署到生产环境中，但是出于业务考虑，可以选择不部署。如果要实施持续部署，必须先实施持续交付。

持续交付并不是指软件每一个改动都要尽快部署到产品环境中，它指的是任何的代码修改都可以在任何时候实施部署。

持续交付表示的是一种能力，而持续部署表示的则一种方式。持续部署是持续交付的最高阶段。更多关于构建企业自动化运维平台系列的学习文章，请参阅：企业级自动化运维平台，本系列持续更新中。

CT

CT(continus testing，持续测试）。完成 CI 中构建及单元测试和集成测试的自动化流程后，持续交付可自动将已验证的代码发布到存储库。为了实现高效的持续交付流程，务必要确保 CI已内置于开发管道。持续交付的目标是拥有一个可随时部署到生产环境的代码库。

CI、CD、DevOps关系

概念性的内容，每个人的理解都有所不同。就好比CGI 这个词，即可以理解成CGI这种协议，也可以理解成实现了CGI协议的软件工具，都没有问题，咬文嚼字过犹不及。留下一图：更多关于构建企业自动化运维平台系列的学习文章，请参阅：企业级自动化运维平台，本系列持续更新中。

参考文章：https://blog.csdn.net/m0_63325890/

article/details/128481397 https://blog.csdn.net

/nkGavinGuo/article/details/131455893

https://blog.csdn.net/weixin_45565886/article/

details/129763344 blog.jjonline.cn/linux/238.html

— 特色专栏 —

MySQL|PostgreSQL|Redis|MongoDB|Tools

ElasticSearch|Kubernetes|Docker|Hadoop

Kafka|RabbitMQ|Zookeeper|OpenStack

企业监控平台|应用与服务|DevOps|集群管理