改进持续交付中的CI环节

改进持续交付中的CI环节

在当前 DevOps 的趋势下，持续集成（CI）和持续部署（CD）具有支柱性地位，那么能够成功搭建 CI/CD 流水线就至关重要了。

今天我就讲一讲如何做好CI部分，让我们的的整个流水线更加的清晰和敏捷

 

如下图是整个CI/CD的部分，当然我们可以根据企业需求扩展CI或者CD的部分让我们的软件工程质量更好(from infoq)

 

 

 

 

终极CI工具：jenkins

我们的目标是要将软件开发生命周期的整个过程都自动化，从开发人员向代码库中提交代码开始，到将此代码投入生产环境中使用为止。

为了使整个软件开发流程处于 DevOps 模式或自动化模式，我们就需要对 CI/CD 流水线进行自动化。因此，我们还需要一款自动化工具来做这件事情，它就是 Jenkins。（from infoq）

首先，我们需要拥有一个可以供开发人员提交代码的仓库。同时，Jenkins 也提供了前端展示的页面，我们可以使用该前端页面来定义整个流水线的作业（job）和任务（task）。对于某一个应用程序而言，我们的目标就是通过特定的工具实现其持续集成和持续交付的自动化流程。

Jenkins 会从 Git 代码仓库中拉取各个分支的代码，然后将其移动到 “代码提交阶段”。拉取到各个分支的代码之后，Jenkins 就会将其继续移动到“构建阶段”，该阶段会对代码进行编译工作。如果是像 Java 这类语言的话，我们还可以在 Jenkins 中选用 maven 之类的构建工具，通过 maven 对代码进行编译。之后在部署过程中，还可以将编译好的代码进行一系列的测试，同时这些测试也会由 Jenkins 监督执行。

之后，Jenkins 就会将代码移动到准生产环境，并使用 Docker 进行部署。在准生产环境中会运行一系列单元测试和可用性测试。如果能够通过所有的测试，Jenkins 就会将它继续移动到生产环境中。

大家也能感受到jenkins可以参与到整个CI的生命周期，好处显而易见

 

 

jenkins完成整个CI的弊端

大家都知道，软件发展至今已经相当成熟了，现在越来越多的重视软件交付质量，会在持续交付过程中集成sonar检查，并添加code review环节，用jenkins做sonar检查的环节和跑单元测试时，通常构建的是主干分支，此时如果sonar或者单元测试没过，其实已经污染到了主干分支，而且平时并不好做code review

采用gitlab完善CI流程

现在绝大部分公司都已经采用gitlab来管理公司的代码，作为代码仓库，gitlab有着强大的功能集，可以做ci/cd

1. 采用gitlab作为代码管理仓库
2. 安装git runner（为了保障性能可以用另外的机器）
3. 采用sonar做代码质量分析工具(并安装gitlab相关插件)
4. 为需要做ci的项目加上.gitlab-ci.yml文件（pipeline流水）

yml文件讲解

stages:
  - test
  - sonar
​
​
test:
  stage: test
  script: /gitlab/auto_test.sh
  except:
    - merge_requests
sonar:
  stage: sonar
  script:
    - echo $CI_COMMIT_REF_NAME
    - echo $CI_PROJECT_ID
    - echo $CI_COMMIT_SHA
    - /gitlab/sonar_preview.sh
    - /gitlab/sonar_analyze.sh
  except:
    - merge_requests
​
  tags:
    - lchen-CI

1.stages: 定义的是gitlab跑pipeline时的步骤

2.scripe: 表示会每个步骤跑的脚本

3.except: 表示gitlab在代码的哪个阶段或者分支时跑（merge_requests表示feature合并到主干分支时会自动跑pipeline，也就是提交merge request的时候）

4.tags: 具体运行pipeline的机器（git runner）

 

下图是我搭建完成后的效果：当test或者sonar有一个环节不通过时，merge就会变成红色，这样就能保证，每个人的feature分支在合并到主干分支之前已经经过自动化工具的检测，保证主干分支代码的干净