本篇译自：levelup.gitconnected.com/basics-of-c…
CI 全名是 Continuous Integration —— 持续集成；
CD 全名是 Continuous Delivery —— 持续交付；
任何商业软件项目都希望通过业务流程的自动化来迅速盈利。迭代快、发布快、更新稳定，就意味着项目能走得更远；
虽然，这个过程可以手动，但是手动克隆代码库、手动链接远程服务器、手动构建、手动运行命令等，任何一个手动的过程都意味着比自动要承受更大的出错风险！
CI
CI 持续集成 描述了存储库变更过程，如图：
我们可以协同工作，最后的更改都会应用到 master 分支上；但这样一个简单的模型也隐藏着一些问题：
一、 如何知道 master 分支的代码部署成功了？
二、 如何验证单元测试的覆盖率？
三、 如何判断团队成员是否按统一的代码规范来编码？
这些问题也可以手动验证，但就是麻烦、低效、易出错；不如交给自动化的 CI ，它就是来干这个的！
第一点：如何知道 master 分支的代码部署成功了？
CI 过程如下：
- 每次推送更改时，Git 服务器都会向 CI 服务器发送一个通知；
- CI 服务器克隆存储库，检出分支，并与主分支合并；
- 然后启动构建脚本；
- 如果返回 Code 为 0，则表示构建成功。否则，被视为失败；
- CI 服务器将带有构建结果的请求发送到 Git 服务器；
- 如果构建成功，则允许合并请求。否则，合并被阻止；
这个过程保证合并到主分支的代码不会破坏构建！
第二点：测试覆盖率检测！
在任何时候，master 分支的测试覆盖率都不应低于 50%；我们可以借助 Jacoco plugin 插件来实现这一检测；
但是，如何使用这个插件，也需要去探究：并不是所有代码都该去遍历~
借助 SonarCloud ，可以实现只检查新增代码的测试覆盖率！
第三点：统一代码风格；
可以借助 Checkstyle 插件！比如代码中有一个未使用的 import ，则直接返回构建失败；当然，这个可以根据项目需求来个性配置；
CD
CD 持续交付 描述了项目新版本自动部署的过程~
一图胜千言：
之前的 CI 服务器演变成了现在的 CI/CD 服务器，你可以将 CI 作业委派给 GitLab CI，将 CD 作业委派给 Jenkins。
CI 部分前面已经说过，下面讲下 CD 细节；
实际上，我们可以在多个阶段进行部署操作：
- 请求合并时部署；
- 定时器部署；
- Pull Request 合到特定分支时进行部署；
- 还可组合以上选项；
了解部署过程、选择合适的部署方式很重要，部署就是版本的发布！
这里提供一些常用的 CI/CD 工具：Jenkins、GitHub Actions、GitLab CI、Travis CI
OK，以上就是本篇分享啦~
撰文不易，点赞鼓励👍👍👍👍👍👍
