4 张图了解 CI/CD 基础~

CI 全名是 Continuous Integration —— 持续集成；

CD 全名是 Continuous Delivery —— 持续交付；

任何商业软件项目都希望通过业务流程的自动化来迅速盈利。迭代快、发布快、更新稳定，就意味着项目能走得更远；

虽然，这个过程可以手动，但是手动克隆代码库、手动链接远程服务器、手动构建、手动运行命令等，任何一个手动的过程都意味着比自动要承受更大的出错风险！

CI

CI 持续集成 描述了存储库变更过程，如图：

我们可以协同工作，最后的更改都会应用到 master 分支上；但这样一个简单的模型也隐藏着一些问题：

一、 如何知道 master 分支的代码部署成功了？

二、 如何验证单元测试的覆盖率？

三、 如何判断团队成员是否按统一的代码规范来编码？

这些问题也可以手动验证，但就是麻烦、低效、易出错；不如交给自动化的 CI ，它就是来干这个的！

第一点：如何知道 master 分支的代码部署成功了？

CI 过程如下：

1. 每次推送更改时，Git 服务器都会向 CI 服务器发送一个通知；
2. CI 服务器克隆存储库，检出分支，并与主分支合并；
3. 然后启动构建脚本；
4. 如果返回 Code 为 0，则表示构建成功。否则，被视为失败；
5. CI 服务器将带有构建结果的请求发送到 Git 服务器；
6. 如果构建成功，则允许合并请求。否则，合并被阻止；

这个过程保证合并到主分支的代码不会破坏构建！

第二点：测试覆盖率检测！

在任何时候，master 分支的测试覆盖率都不应低于 50%；我们可以借助 Jacoco plugin 插件来实现这一检测；

但是，如何使用这个插件，也需要去探究：并不是所有代码都该去遍历~

借助 SonarCloud ，可以实现只检查新增代码的测试覆盖率！

第三点：统一代码风格；

可以借助 Checkstyle 插件！比如代码中有一个未使用的 import ，则直接返回构建失败；当然，这个可以根据项目需求来个性配置；

CD

CD 持续交付 描述了项目新版本自动部署的过程~

一图胜千言：

之前的 CI 服务器演变成了现在的 CI/CD 服务器，你可以将 CI 作业委派给 GitLab CI，将 CD 作业委派给 Jenkins。

CI 部分前面已经说过，下面讲下 CD 细节；

实际上，我们可以在多个阶段进行部署操作：

1. 请求合并时部署；
2. 定时器部署；
3. Pull Request 合到特定分支时进行部署；
4. 还可组合以上选项；

了解部署过程、选择合适的部署方式很重要，部署就是版本的发布！

这里提供一些常用的 CI/CD 工具：Jenkins、GitHub Actions、GitLab CI、Travis CI

OK，以上就是本篇分享啦~

撰文不易，点赞鼓励👍👍👍👍👍👍

我是掘金安东尼，公众号同名，日拱一卒、日掘一金，再会~