金丹境-第5层 CI和CD 流程的整合

整个devops 流程的话，其实应该各个平台都是打通的，例如禅道，jenkins ， gitlab，habor ; 禅道是用来做项目管理的，这样的话，其实在做代码的构建触发点，应该基于禅道的任务的完成状态和需求的流转，做自动化的构建。

CI：对于代码持续集成

持续集成的目的，就是让产品可以快速迭代，同时代码还能保持高质量，那么自动化测试覆盖率就很关键。

功能点

提交格式的校验，commit message 和代码格式检查

2.自动化测试的校验。使用一些测试框架，构建时走测试命令，出测
试报告覆盖率

不采用服务端git-hooks方式

工具插件

首先,java项目大部分都采用的maven 构建或者gradle 构建，本例按照gradle 说明；

husky --- git-hooks 工具，用它就是在客户端配置钩子
commitlint ,conventional-changelog 一些git提交信息格式的校验工具,changeLog.md
jacoco+spock --单元测试覆盖率工具
ESLint+Prettier 主要解决的是前端的代码格式问题
Checkstyle 检查后端的代码格式
H2 数据库，加上初始化脚本，配合单元测试使用

以上的一些组件基本都是使用gradle 插件的方式进行安装的，不过spock 单元测试用例的话，需要和代码结合

CI实现的过程

首先，我们借鉴了前端的代码检查方式，对于整体项目，引入了node 安装 husky插件，进行钩子的配置；
package.json

{
    "devDependencies": {
        "@commitlint/cli": "^8.0.0",
        "@commitlint/config-conventional": "^8.0.0",
        "commitizen": "^4.0.3",
        "cz-conventional-changelog": "^3.0.2",
        "husky": "^3.0.0"
    },
    "config": {
        "commitizen": {
            "path": "./node_modules/cz-conventional-changelog"
        }
    },
    "husky": {
        "hooks": {
            "commit-msg": "commitlint -E HUSKY_GIT_PARAMS",
            "pre-commit": "gradlew -Djacoco.packageInstructionCoverageRuleEnabled=false -Djacoco.bundleInstructionCoverageRuleEnabled=false -Djacoco.bundleBranchCoverageRuleEnabled=false -Dorg.gradle.daemon=true build",
            "pre-push": "gradlew -Djacoco.packageInstructionCoverageRuleEnabled=false -Djacoco.bundleBranchCoveredRatio=0.4 -Djacoco.bundleInstructionCoveredRatio=0.4 -Dorg.gradle.daemon=true build"
        }
    },
    "scripts": {
        "commit": "git-cz -s"
    }
}

关于这个的集成，其实项目变更上很简单，开发安装了node,通过 npm install 安装以上插件即可；也可以封装一个模板项目，这样新项目就比较简单了，目前我司实现的就是模板项目。

然后可以结合一些gradle任务的执行：

./gradlew check 检查代码风格
./gradlew test --走单元测试
这些命令都可以在husky里的钩子里进行配置.
测试报告和代码分格检查的结果是一定要有的。这样在无法提交的时候，可以明确的知道是代码格式问题还是单元测试覆盖率没达标导致的无法提及。

正常的代码，通过在客户端idea等集成环境，完成了代码的质量控制。

CD，持续交付

Jenkins 做的交付引擎

人工按钮的控制，不使用gitlab 的webhooks 自动build ，自动build 可能会影响测试。
拉去代码，build , 跳过测试，通过docker 命令或者组件构建docker 镜像
push 镜像到远程仓库
开始读取项目中的k8s-publish.yml 文件，通过k8s-cd 模板控制项目，生成对应的发布文件（deployment,service,configmap）等。此时的配置包括资源的控制，如cpu，内存，实例数目，升级策略，是否健康检查，服务名，保留的端口方式，通过k8s-publish.yml 生成configmap 文件挂在进入容器
提交生成好的文件。k8s 自行构建
清理资源，包括已经推送到远程的镜像，否则本地迟早磁盘空间不足

以上都是比较细节的东西，CI，CD大部分都是使用工具链的方式，通过流水线作业stage 的方式把每个步骤串行起来执行。

大厂一般会在这些基础的工具链上封装一层控制平台，但是底层其实还是基于了这些组件的使用。

最后编辑于：2020.08.14 17:01:14