持续集成概述及运行流程

最新推荐文章于 2024-09-18 07:15:00 发布

癞疙宝། – _ – །

最新推荐文章于 2024-09-18 07:15:00 发布

阅读量685

点赞数 1

分类专栏： GitLab 与 Jenkins 结合构建持续集成环境文章标签： jenkins ci 运维

本文链接：https://blog.csdn.net/m0_56342013/article/details/125502545

版权

本文介绍了持续集成（CI）和持续部署（CD）的概念及其流程，强调了它们在提高开发效率和保持软件质量中的作用。详细讲解了Jenkins和GitLab在CI/CD中的角色，并概述了从提交代码到生产部署的完整过程，包括自动化测试、构建、部署和回滚等关键步骤。

摘要由CSDN通过智能技术生成

1、持续集成概述及运行流程

1.1、CI/CD介绍

把开发工作流程分为以下几个阶段：

编码 → 构建 → 集成 → 测试 → 交付 → 部署

正如你在上图中看到，持续集成(Continuous Integration)、持续交付(Continuous Delivery)和持续部署(Continuous Deployment)有着不同的软件自动化交付周期。

1.1.1、概念

本文简要介绍持续集成的概念。

持续集成

持续集成（Continuous integration）是指开发者在代码的开发过程中，可以频繁的（一天多次）将代码合并到主干源码仓库，并立刻进行构建、（单元）测试。根据测试结果，我们可以确定新代码和原有代码能否正确地集成在一起。

它的好处主要有两个：

快速发现错误。每完成一点开发，就集成到主干，可以快速发现错误，定位错误也比较容易；
防止分支大幅偏离主干。如果不是经常集成，主干又在不断更新，会导致以后集成的难度变大，甚至难以集成。

持续集成的目的，就是让产品可以快速迭代，同时还能保持高质量。它的核心措施是，代码集成到主干之前，必须通过自动化测试。只要有一个测试用例失败，就不能集成。持续集成并不能消除Bug，而是让它们非常容易发现和改正。

持续交付：

持续交付（Continuous delivery）指的是在持续集成的基础上，将集成后的代码部署到更贴近真实运行环境(类生产环境)中。比如，我们完成单元测试后，可以把代码部署到连接数据库的Staging环境中，做更多的测试。如果代码没有问题，就可以手动部署到生产环境。 Staging [ˈsteɪdʒɪŋ] 临时工作台

持续交付可以看作持续集成的下一步。它强调的是，不管怎么更新，软件是随时随地可以交付的。