你真的懂持续集成、持续交付、持续部署吗？！
什么是集成？
在传统的软件开发中，集成通常是在每个人完成工作后的项目结束时进行
实际栗子
- 现在有一个电商平台需要开发
- 由于电商平台模块众多，需要不同的开发人员开发不同的模块【本地开发】
- 最后将所有人开发好的代码集成到一个系统中【提交代码到远程仓库】
- 集成完成后需要对其进行部署上线
- 随着时间的推移，该系统无论是 Bug 修复，还是新功能开发，后续都需要对系统进行不断的更新迭代
- 重点：所有人最终开发完才集成
什么是持续集成 CI？
- 持续集成指的是，频繁地（一天多次）将所有开发者的代码集成到主干
- 简单理解：重复集成的工作
持续集成的流程
- 开发人员（10101）提交代码到 Source Repository （源代码仓库，如 Gitlab）
- 有代码更新到代码仓库后，会通过 WebHook 触发 CI Server（持续集成服务器，如 Jenkins）的相关功能，执行编译-测试-输出结果的流程
- CI Server 会将执行结果返回给开发人员
注意
这里的测试并不是常规的功能测试，而是针对代码的单元测试
持续集成的好处
快速发现错误
- 每完成一点更新，就集成到主干，相当于将一个复杂的模块细分成一个个小模块
- 每次小模块集成后再进行测试，可以快速发现错误，定位错误更加容易
节省人力成本，加快软件开发进度
- 如果 Build-Test 这种重复性工作需要人工执行将会耗费很多时间
- 现在交给 CI Server 自动化执行，节约了很多时间，从而投入到有价值的工作中去
控制开发流程，实时交付
- 细分的代码提交，可以更容易判断当前的开发进度
- 这让管理者更容易管控整个开发流程，从而保证产品实时交付
易于 CodeReview
对于大块工作的切分自然也有助于做 CodeReview
持续集成的核心
确保新增的代码能够与原有代码正确的集成
持续集成的目的
让产品可以快速迭代，同时还能保持高质量，简化工作流程
核心措施
- 代码集成到主干之前，先进行自动化单元测试
- 只要有一个测试用例失败，就不能集成
- 持续集成并不能完全的消除 Bug，而是让它们非常容易发现和改正
什么情况下需要持续集成
- 如果项目开发的规模比较小，就不需要持续集成
- 如果项目很大，需要不断添加新功能或不断的升级产品，代表需要反复集成，这个时候就需要用到持续集成来简化我们的工作
重点
- 持续集成仅仅是让所有开发提交的代码成功集成到系统中并正常协同工作
- 但并没有经过测试工程师的测试和严重，所以集成的代码并不能马上发布到生产环境
什么是持续交付 CD？
wiki 给的说明
持续交付是一种软件工程方法，团队可以在短时间内生产软件，以确保可以随时可靠地发布软件，并且在发布软件时，可以手动进行发布。
简单理解
频繁地将软件的新版本，交付给质量团队或者用户，以供测试/评审。如果测试/评审通过，代码就进入生产阶段
持续交付的流程
- 代码提交
- 单元测试
- 集成代码
- 测试（Test）：这里不仅仅是单元测试，还可能包含功能测试、集成测试、系统测试等
- 先部署到预发环境（预生产环境，Staging）：测试人员在预发环境进行产品的主流程验证，验证通过再执行下一步
- 手动部署到生产环境（Production）：开发手动部署
持续交付的重点
- 持续集成的重点是代码，但持续交付的重点是可交付的产品
- 可交付的产品一定要有达标的质量，确保产品在生产环境没问题，所以在成功集成代码之后，还需要进行测试（TEST）
什么是持续部署 CD？
wiki 给的说明
通过自动化部署的手段将软件功能频繁的进行交付
通俗理解
- 持续部署是持续交付的下一步
- 代码在任何时刻都能部署
- 最后将部署到生产环境的过程自动化
和持续交付的区别
- 持续交付：代码最终部署到生产环境的过程是手动的（Manual）
- 持续部署：代码最终部署到生产环境的过程是自动化的（Auto）
持续部署的流程
- 将最后一步的 Production 自动化
- 开发人员提交代码到编译、测试、部署的全流程都不需要人工干预，完全自动化执行
持续部署的优势
这一策略加快了代码提交到功能上线的速度，保证新的功能能够第一时间部署到生产环境并被使用
持续部署的不足
- 全流程自动化，无法保证质量，哪一步出问题了无法提前预知
- 目前一个产品正常发布到生产环境，还是需要测试工程师进行手工功能测试的
- 所以持续交付更主流，因为它算半自动化
