总结

CI/CD应用场景：

• 开发人员将本地代码上传gitlab版本服务器
• jenkins通过webhook插件自动到gitlab服务器拉取最新代码
• 通过docker-maven-plugin插件自动编译代码
• 将自定义镜像上传docker私服仓库
• k8s集群自动拉取最新版本镜像
• 自动化部署整个项目
• 用户通过nginx负载均衡访问整个项目  

什么是持续集成、持续交付和持续部署 ？

持续集成（CI）  

 是一种开发实践，要求开发人员每天多次将代码集成到共享存储库中(GitLab)。

开发人员通常使用称为CI Server的工具来进行构建和集成。CI要求自检代码。这是用于自我测试以确保其按预期工作的代码，这些测试通常称为单元测试。集成代码后，当所有单元测试通过时，将得一个最新的的代码版本。这表明他们已经验证了自己的更改已成功集成到一起，并且代码按测试期望的那样工作。 

• 开发人员提交代码到 Source Repository （源代码仓库），并通过 git hook 等
• 触发 CI Server（持续集成服务器）的相关功能。执行 编译 -> 测试 -> 输出结果的流程，
• 向开发人员反馈结果的 report

连续交付（CD）  

是一种软件工程方法，团队可以在短时间内将软件部署到生产环境，确保在任何时候可靠地发布软件，并且在发布软件时可以手动进行。

持续交付意味着每次更改代码，集成并构建代码时，他们还将在与生产非常相似的环境中自动测试该代码。我们将此部署到不同环境并在不同环境上进行测试的过程称为部署管道。部署管道通常具有开发环境，测试环境和过渡环境，但是这些阶段因团队，产品和组织而异。 

与持续集成相比，持续交付的侧重点在于交付，其核心对象不在于代码，而在于可交付的产物。由于持续集成仅仅针对于新旧代码的集成过程执行了一定的测试，其变动到持续交付后还需要一些额外的流程。

可以看到，与 持续集成 相比较，持续交付 添加了 Test -> Staging -> Production 的流程，也就是为新增的代码添加了一个保证：确保新增的代码在生产环境中是可用的 。

在这一增加的流程中，Test 环节不仅仅包含基本的单元测试，还需要延伸到更为复杂的功能测试以及集成测试等。在这里，Staging 指的是 类生产环境 ，其尽可能的对真实的网络拓扑、数据库数据以及硬件设备等资源进行模拟，从而为测试人员反馈代码在生成环境中的可能表现。流程中每一个环节的执行结果都会对开发人员进行反馈，每一个出现的错误都会导致版本的回滚。当测试完毕确认无误之后，将由相关人员对其进行手动部署到生产环境。

持续部署  

DevOps概述  

介绍完了持续集成、持续交付和持续部署三大件，接下来在讲讲 DevOps。与三大件不同，DevOps 更偏向于一种对于文化氛围的构建。

DevOps 一词本身是对于 development 以及 operation 两个词的混合，其目的在于缩短系统开发的生命周期，在这过程中发布特性、修复bug以及更新均被紧密的结合。

听起来似乎有点玄乎，可以这样理解：DevOps 也即是促使开发人员与运维人员之间相互协作的文化。

DevOps 的概念似乎与持续交付的概念有些类似，两者均旨在促进开发与运维之间的协作，但是实际上两者差别很大：DevOps 更偏向于一种文化的构建，在 DevOps 文化指导下，团队中将包含了具有不同技能的人员（开发、测试等），并通过自动化测试与发布的手段，更快、更高质量的生产软件。

在传统的团队组织方式中，开发人员与运维人员之间是割裂开的，软件开发流程被分割为多个独立环节，分别由不同的人员执行。这使得软件开发过程中需要付出高昂的沟通成本，层层手动的流程将大量的时间耗费在了重复的劳动中。

在 DevOps 的指导下，不同技能的人员处在同个团队中，为了一个共同的软件开发目标而工作，更好的协同工作与自动化的手段能够优化整个 Code -> Build -> Test -> Release -> Operate -> Code 的循环。这一理念看起来很美，用图画来说明就构成了一个和谐友好的大圈。

DevOps文化通常与持续交付相关联，因为它们都旨在增强开发人员和运营团队之间的协作，并且都使 用自动流程来更快，更频繁，更可靠地构建，测试和发布软件。这些都是像我们这样的人想要的东西。尽管开发团队经常没有看到流程改进的最直接好处，但CI，CD和DevOps对我们其他人来说却有很多好处。简而言之，我相信实践CD并拥护DevOps文化的组织将更频繁地向其客户提供更有价值，更可靠的软件。  

链接：https://blog.csdn.net/m0_58026506/article/details/120039743

（版权归原作者所有，侵删）