徒弟：“弟子愚钝，在刻剑的过程中倍觉无聊，又不喜欢哼歌，于是索性边练咒边刻剑。后面徒儿发现，如果刻错了或者念错了，飞剑就会提前直接爆炸，虽然每次炸的内裤都没了，但是能够尽早发现错误。所以徒弟才能一日千里”。
师父摸了摸胡须道：“然来如此！不过，这就是你大庭广众之下裸奔的借口！！？”
Docker和持续集成（CI）相比其他技术，Docker在持续集成（CI）这块有着先天的优势。在通常的情况下，我们要实现持续集成往往会遇到以下问题：
l 复杂的依赖关系
不同的项目环境，不同的语言，不同的程序包依赖，甚至是操作系统的依赖等等，都会影响到我们持续集成的自动化脚本的执行。而且依赖包之间的兼容性，版本的兼容性，间接依赖或者多重依赖等问题等等，对于开发和运维来说，都是一个噩梦。就如以下对话：
徒弟：“师父，我按照您教的方式念咒，为什么飞剑飞起来了之后就收不回来了？”。
师父直接一巴掌，说：“兔崽子，上次就和你说了，咒语现在最低的兼容级别是——普通话二级乙等！谁教你说长沙话的！”
l 不一致的环境
在通常的环境中，我们需要准备好开发、测试和生产环境，往往开发环境随便开发人员折腾，有时候操作系统或者依赖软件的版本的区别、组件的不同、配置不一样，都足够让开发环境正常运行的程序在测试环境上跑不起来，造成测试人员和开发人员的故意伤害事件，导致“行凶人员”后悔终生，感悟到“冲动就是魔鬼”的箴言。我们还是以对话来阐述这个问题：
徒弟拿出普通话二级乙等证书道：“师父，我苦学普通话，终于达到普通话二级乙等。然后按照您教的方式念咒了，之后为什么飞剑飞起来了之后还是没法收回来？”。
师父又是一巴掌，说：“兔崽子，你没看到下雨了么？”
徒弟弱弱的问：“这个和下雨有关系么？是不是雨天法术受雨滴干扰，咒语的效果受到影响呢？”
师父指着外面道：“瞎了？你丫的不赶紧把被子收回来烘干，你的飞剑就甭想要了！”
l 应用架构的复杂性和配置的多样性
现在的系统架构越来越复杂，甚至由多种开发语言组成，而且包含前后端等多方面内容。这些可能会导致其部署方式的不同以及配置的复杂性。并且一个系统维护到后面，往往有很多历史遗留问题，比如那各种配置文件和配置方式，各种补丁，各种脚本等等。这些因素会导致自动化流程会非常麻烦和艰难。我们继续来一段对话：
徒弟：“师父，被子收好了，但是飞剑越飞越远了，是不是可以教我收回我的飞剑啦！”。
师父张开一只眼：“小崽子，普通话念完后，用长沙话再念一遍收剑咒！前几天，为师对收剑咒又进行了改造。”
徒弟用长沙话念完，飞剑还是再天空中乱窜，并没有降下来的意思。徒弟赶紧问道：“师父，为啥还是不行呢？”
师父弹了弹手指，远处一根若隐若现的细线展现出来，师父指着那根线说：“看到那边那根线没？还不赶紧去追！”
相比这些问题，Docker实现持续集成（CI）就方便多了。
首先，Docker可以让我们非常容易和方便地以“容器化”的方式去部署应用。它就像集装箱一样，打包了所有依赖，再在其他服务器上部署很容易，不至于换服务器后发现各种配置文件散落一地，这样就解决了编译时依赖和运行时依赖的问题。
其次，Docker的隔离性使得应用在运行时就像处于沙箱中，每个应用都认为自己是在系统中唯一运行的程序，这样就可以很方便地在一个系统中部署多种不同环境来解决依赖复杂度的问题。
正因为Docker是以应用为中心，镜像中打包了应用及应用所需的环境，一次构建，处处运行。这种特性完美解决了传统模式下应用迁移后面临的环境不一致问题。
因此使用Docker实现持续集成，我们可以使用一些简单的免费的工具即可实现，也可以非常方便的自己搭建集成环境或者编写脚本实现。比如Azure DevOps、Tencent Hub、Jenkins和TeamCity，接下来我们会逐步进行介绍。
一般情况下，持续集成的流程如下所示：
下面是一个参考流程：
代码版本管理，我们推荐使用Git。关于git版本库的使用，我这里就不啰嗦了，如果有朋友感兴趣，我也可以分享一些内容。