持续集成概述及运行流程

目录

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

1.1、CI/CD介绍

1.1.1、概念

1.1.2、流程

1.2、jenkins概述

 1.3、GitLab概述：

 1.4、项目部署方式

 1.5、集群和分布式

1.6、持续集成系统的工作流程

总结： 

---

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

1.1、CI/CD介绍

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

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

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

1.1.1、概念

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

• 持续集成

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

 它的好处主要有两个：

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

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

• 持续交付：

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

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

 

•  持续部署：

       持续部署（continuous deployment）是持续交付的下一步，指的是代码通过评审以后，部署到生产环境。

持续部署的目标是，代码