在本系列教程中,笔者但愿将必要的知识点围绕理论、流程(工做流程)、方法、实践来进行讲解,而不是单纯的为讲解知识点而进行讲解。也就是说,笔者但愿可以让你们将理论、知识、思想和指导应用到工做的实际场景和实践之中,而不是拿着字典写文章,抱着宝典写代码。至于不少具体的语法、技术细节,除了经常使用的知识点,笔者更但愿你们阅读官方文档——毕竟看官网比看书靠谱多了,官网会一直更新和改进,而书和教程自出版或发布以后,基本上就“死“了。html
本系列教程预计所有完成还须要2到3个月的时间。在这个过程当中,您能够和咱们一块儿讨论、交流和分享这一块的技术。咱们也但愿获得你们的支持,请多多点赞,大家的支持是咱们前进的最大动力!git
咱们先得了解持续集成的相关概念,才能更好地指导开发和使用Docker来改进咱们的工做流。和其余教程不同,笔者更喜欢将必要的知识点围绕理论、流程(工做流程)、方法、实践来进行讲解,而不是单纯的为讲解知识点而进行讲解。也就是说,笔者但愿为你们打通任督二脉,可以将理论、知识、思想和指导应用到工做的实际场景和实践之中,而不是拿着字典写文章,抱着宝典写代码。至于不少具体的语法、技术细节,除了经常使用的知识点,笔者更但愿你们阅读官方文档——毕竟看官网比看书靠谱多了,官网会一直更新和改进,而书和教程自出版或发布以后,基本上就“死“了。后端
好了,咱们回到正题。持续集成是一种软件开发实践,即团队开发成员常常集成他们的工做,一般每一个成员天天至少集成一次,也就意味着天天可能会发生屡次集成。每次集成都经过自动化的构建(包括编译,发布,自动化测试)来验证,从而尽早地发现集成错误。服务器
徒弟一脸崇拜道:“师父,为何我作出来的飞剑,一念咒语不是碎了就是爆了呢?”。架构
师父摸了摸胡子道:“徒儿莫急,冰冻三尺非一日之寒!为师我刻了3年的阵法,练习了3年的咒语,而后又花了3年一块儿练习,才让第一把飞剑飞上了太空。我看你天资聪慧,顶多20年就够了”。运维
2年后,徒弟边刻阵法边念咒,忽然飞剑的剑身嗖的一下不见了,只余剑柄。工具
师父:“徒儿,你的飞剑怎么飞了一截出去了!”post
徒弟握着剑柄行礼道:“师父勿怪,这段时间我对飞剑的制做过程进行了改良,一边刻阵法一边念咒,如今我对阵法和咒语的掌控都达到了70%,因此只有前半截飞出去了!“测试
注意:集成软件的过程不是新问题,若是项目开发的规模比较小,好比一我的的项目,若是它对外部系统的依赖很小,那么软件集成不是问题,可是随着软件项目复杂度的增长(即便增长一我的),就会对集成和确保软件组件可以在一块儿工做提出了更多的要求-要早集成,常集成。早集成,频繁的集成帮助项目在早期发现项目风险和质量问题,若是到后期才发现这些问题,解决问题代价很大,颇有可能致使项目延期或者项目失败。url
1.统一的代码库
2.自动构建
3.自动测试
4.每一个人天天都要向代码库主干提交代码
5.每次代码递交后都会在持续集成服务器上触发一次构建
6.保证快速构建
7.模拟生产环境的自动测试
8.每一个人均可以很容易的获取最新可执行的应用程序
9.每一个人都清楚正在发生的情况
10.自动化的部署
1. 全部的开发人员须要在本地机器上作本地构建,而后再提交的版本控制库中,从而确保他们的变动不会致使持续集成失败。
2. 开发人员天天至少向版本控制库中提交一次代码。
3. 开发人员天天至少须要从版本控制库中更新一次代码到本地机器。
4. 须要有专门的集成服务器来执行集成构建,天天要执行屡次构建。
5. 每次构建都要100%经过。
6. 每次构建均可以生成可发布的产品。
7. 修复失败的构建是优先级最高的事情。
8. 测试是将来,将来是测试
持续集成咱们就先说到这里,建议你们也能够了解下敏捷开发,毕竟持续集成是敏捷开发的基石,可是敏捷开发是一个大命题,这里咱们顺带提一下,而后咱们仍是先继续本篇教程:
师父:“徒儿,你真的在短短3年就让飞剑飞起来了?”。
徒弟:“弟子愚钝,在刻剑的过程当中倍觉无聊,又不喜欢哼歌,因而索性边练咒边刻剑。后面徒儿发现,若是刻错了或者念错了,飞剑就会提早直接爆炸,虽然每次炸的内裤都没了,可是可以尽早发现错误。因此徒弟才能一日千里”。
师父摸了摸胡须道:“然来如此!不过,这就是你大庭广众之下裸奔的借口!!?”
相比其余技术,Docker在持续集成(CI)这块有着先天的优点。在一般的状况下,咱们要实现持续集成每每会遇到如下问题:
l 复杂的依赖关系
不一样的项目环境,不一样的语言,不一样的程序包依赖,甚至是操做系统的依赖等等,都会影响到咱们持续集成的自动化脚本的执行。并且依赖包之间的兼容性,版本的兼容性,间接依赖或者多重依赖等问题等等,对于开发和运维来讲,都是一个噩梦。就如如下对话:
徒弟:“师父,我按照您教的方式念咒,为何飞剑飞起来了以后就收不回来了?”。
师父直接一巴掌,说:“兔崽子,上次就和你说了,咒语如今最低的兼容级别是——普通话二级乙等!谁教你说长沙话的!”
l 不一致的环境
在一般的环境中,咱们须要准备好开发、测试和生产环境,每每开发环境随便开发人员折腾,有时候操做系统或者依赖软件的版本的区别、组件的不一样、配置不同,都足够让开发环境正常运行的程序在测试环境上跑不起来,形成测试人员和开发人员的故意伤害事件,致使“行凶人员”后悔终生,感悟到“冲动就是魔鬼”的箴言。咱们仍是以对话来阐述这个问题:
徒弟拿出普通话二级乙等证书道:“师父,我苦学普通话,终于达到普通话二级乙等。而后按照您教的方式念咒了,以后为何飞剑飞起来了以后仍是无法收回来?”。
师父又是一巴掌,说:“兔崽子,你没看到下雨了么?”
徒弟弱弱的问:“这个和下雨有关系么?是否是雨天法术受雨滴干扰,咒语的效果受到影响呢?”
师父指着外面道:“瞎了?你丫的不赶忙把被子收回来烘干,你的飞剑就甭想要了!”
l 应用架构的复杂性和配置的多样性
如今的系统架构愈来愈复杂,甚至由多种开发语言组成,并且包含先后端等多方面内容。这些可能会致使其部署方式的不一样以及配置的复杂性。而且一个系统维护到后面,每每有不少历史遗留问题,好比那各类配置文件和配置方式,各类补丁,各类脚本等等。这些因素会致使自动化流程会很是麻烦和艰难。咱们继续来一段对话:
徒弟:“师父,被子收好了,可是飞剑越飞越远了,是否是能够教我收回个人飞剑啦!”。
师父张开一只眼:“小崽子,普通话念完后,用长沙话再念一遍收剑咒!前几天,为师对收剑咒又进行了改造。”
徒弟用长沙话念完,飞剑仍是再天空中乱窜,并无降下来的意思。徒弟赶忙问道:“师父,为啥仍是不行呢?”
师父弹了弹手指,远处一根若隐若现的细线展示出来,师父指着那根线说:“看到那边那根线没?还不赶忙去追!”
相比这些问题,Docker实现持续集成(CI)就方便多了。
首先,Docker可让咱们很是容易和方便地以“容器化”的方式去部署应用。它就像集装箱同样,打包了全部依赖,再在其余服务器上部署很容易,不至于换服务器后发现各类配置文件散落一地,这样就解决了编译时依赖和运行时依赖的问题。
其次,Docker的隔离性使得应用在运行时就像处于沙箱中,每一个应用都认为本身是在系统中惟一运行的程序,这样就能够很方便地在一个系统中部署多种不一样环境来解决依赖复杂度的问题。
正由于Docker是以应用为中心,镜像中打包了应用及应用所需的环境,一次构建,到处运行。这种特性完美解决了传统模式下应用迁移后面临的环境不一致问题。
所以使用Docker实现持续集成,咱们可使用一些简单的免费的工具便可实现,也能够很是方便的本身搭建集成环境或者编写脚本实现。好比Azure DevOps、Tencent Hub、Jenkins和TeamCity,接下来咱们会逐步进行介绍。
通常状况下,持续集成的流程以下所示:
下面是一个参考流程:
代码版本管理,咱们推荐使用Git。关于git版本库的使用,我这里就不啰嗦了,若是有朋友感兴趣,我也能够分享一些内容。
后续,咱们将会分享使用相关工具来实施咱们的CI流程。