在本系列教程中，笔者希望将必要的知识点围绕理论、流程（工作流程）、方法、实践来进行讲解，而不是单纯的为讲解知识点而进行讲解。也就是说，笔者希望能够让大家将理论、知识、思想和指导应用到工作的实际场景和实践之中，而不是拿着字典写文章，抱着宝典写代码。至于很多具体的语法、技术细节，除了常用的知识点，笔者更希望大家阅读官方文档——毕竟看官网比看书靠谱多了，官网会一直更新和改进，而书和教程自出版或发布之后，基本上就“死“了。
本系列教程预计全部完成还需要2到3个月的时间。在这个过程中，您可以和我们一起讨论、交流和分享这一块的技术。我们也希望得到大家的支持，请多多点赞，你们的支持是我们前进的最大动力！
Docker和持续集成（CI） 什么是持续集成？我们先得了解持续集成的相关概念，才能更好地指导开发和使用Docker来改进我们的工作流。和其他教程不一样，笔者更喜欢将必要的知识点围绕理论、流程（工作流程）、方法、实践来进行讲解，而不是单纯的为讲解知识点而进行讲解。也就是说，笔者希望为大家打通任督二脉，能够将理论、知识、思想和指导应用到工作的实际场景和实践之中，而不是拿着字典写文章，抱着宝典写代码。至于很多具体的语法、技术细节，除了常用的知识点，笔者更希望大家阅读官方文档——毕竟看官网比看书靠谱多了，官网会一直更新和改进，而书和教程自出版或发布之后，基本上就“死“了。
好了，我们回到正题。持续集成是一种软件开发实践，即团队开发成员经常集成他们的工作，通常每个成员每天至少集成一次，也就意味着每天可能会发生多次集成。每次集成都通过自动化的构建（包括编译，发布，自动化测试）来验证，从而尽早地发现集成错误。
徒弟一脸崇拜道：“师父，为什么我做出来的飞剑，一念咒语不是碎了就是爆了呢？”。
师父摸了摸胡子道：“徒儿莫急，冰冻三尺非一日之寒！为师我刻了3年的阵法，练习了3年的咒语，然后又花了3年一起练习，才让第一把飞剑飞上了太空。我看你天资聪慧，顶多20年就够了”。
2年后，徒弟边刻阵法边念咒，突然飞剑的剑身嗖的一下不见了，只余剑柄。
师父：“徒儿，你的飞剑怎么飞了一截出去了！”
徒弟握着剑柄行礼道：“师父勿怪，这段时间我对飞剑的制作过程进行了改良，一边刻阵法一边念咒，现在我对阵法和咒语的掌控都达到了70%，所以只有前半截飞出去了！“
注意：集成软件的过程不是新问题，如果项目开发的规模比较小，比如一个人的项目，如果它对外部系统的依赖很小，那么软件集成不是问题，但是随着软件项目复杂度的增加（即使增加一个人），就会对集成和确保软件组件能够在一起工作提出了更多的要求-要早集成，常集成。早集成，频繁的集成帮助项目在早期发现项目风险和质量问题，如果到后期才发现这些问题，解决问题代价很大，很有可能导致项目延期或者项目失败。
核心价值1.统一的代码库
2.自动构建
3.自动测试
4.每个人每天都要向代码库主干提交代码
5.每次代码递交后都会在持续集成服务器上触发一次构建
6.保证快速构建
7.模拟生产环境的自动测试
8.每个人都可以很容易的获取最新可执行的应用程序
9.每个人都清楚正在发生的状况
10.自动化的部署
原则1. 所有的开发人员需要在本地机器上做本地构建，然后再提交的版本控制库中，从而确保他们的变更不会导致持续集成失败。
2. 开发人员每天至少向版本控制库中提交一次代码。
3. 开发人员每天至少需要从版本控制库中更新一次代码到本地机器。
4. 需要有专门的集成服务器来执行集成构建,每天要执行多次构建。
5. 每次构建都要100%通过。
6. 每次构建都可以生成可发布的产品。
7. 修复失败的构建是优先级最高的事情。
8. 测试是未来，未来是测试
持续集成我们就先说到这里，建议大家也可以了解下敏捷开发，毕竟持续集成是敏捷开发的基石，但是敏捷开发是一个大命题，这里我们顺带提一下，然后我们还是先继续本篇教程：
师父：“徒儿，你真的在短短3年就让飞剑飞起来了？”。