持续集成基础概念
持续集成CI（Continuous Integration）是一种软件开发实践，团队成员频繁地将他们的工作成果集成在一起。通常是每人每天至少提交一次，这样每天就有多次集成。每次提交后，自动触发一次包含自动化测试的构建任务，以便能尽早发现集成问题。
通过这种方式，许多团队大大减少了集成阶段的问题。由此可以看出，持续集成是一种质量反馈的机制，能够尽早地发现代码中的问题，并提前解决问题。持续集成这个术语最早是在1994年由Grady Booch提出的，目前能看到的关于持续集成最多的描述，来源于Martin Flower发表的一系列论文。Martin Flower为持续集成总结了以下一些原则：
- 维护一个统一的代码库；
- 每天都必须向主干提交代码；
- 每次提交都应立刻在集成环境进行构建；
- 自动化构建；
- 自动化测试；
- 自动化部署；
- 快速、持续构建；
- 构建环境务必于生产环境保持一致；
- 访问权限对团队成员保持公开透明；
总结：
持续集成中的持续的意思并不是“始终，一直”，它的意思是“随时”。比较恰当的频率是：每当有人提交代码，同时集成一次。
持续集成包括：自动编译+自动代码检查+自动打包+自动化测试+自动部署。
做持续集成的原因
本质：解决项目中常见的问题
- 由于长期在各自的分支上开发，导致在集成阶段合并分支时产生大量冲突，无法合并；
- 由于之前并未进行过任何集成，导致在集成阶段耗时太长，或者根本无法集成；
- 重复进行手工的部署、调试、测试、发布，成本高，风险大；
持续集成的优点
- 持续集成并不能消除bug，却能帮你快速的发现bug并予以清除；
- 持续集成能提升交付效率和交付软件的质量；
- 及时反馈结果，尽早发现问题；
- 自动化代替手工，工程师将更多的时间精力放在设计、需求分析、风险预防等方面；
持续交付
理解了持续集成，持续交付（CD：Continuous Delivery）就很容易掌握了。持续交付在持续集成的基础上，将集成后的代码部署到更贴近真实运行环境的类生产环境中。如果测试没有问题，可以继续手动部署到生产环境中。注意：这里的测试重点是指测试人员进行的产品级别的测试！往往在这个测试过程中普遍都会引入测试脚本进行自动化回归测试，主要是进行接口测试和UI测试（业界公认做法是重接口轻UI），当然部分公司也会引入安全测试和性能测试。持续交付能够以较短地周期完成需求的小粒度频繁交付。频繁的交付周期带来了更迅速的对软件的反馈，并且在这个过程中，各个角色密切协作，相比于传统的瀑布式软件团队，更少浪费。
持续部署
持续部署(CD：Continuous Deployment)则是在持续交付的基础上，把部署到生产环境的过程自动化（如上图）。整个过程无需人工参与！
核心工具的使用
持续集成、持续交付、持续部署是需要大量的工具作为支撑的！整个核心工具链如下图所示：
- 整个流程的串联使用Jenkins
- 代码（java）构建使用git、gitlab、maven、nexus等工具
- 代码的自动化测试使用Junit、sonarqube等工具
- 环境的自动化部署使用docker 、hrbor、kubernetes等工具
- 产品的自动化测试使用selenium、jmeter等工具
- 产品的运行日志分析以及监控使用elastic