gitlab 持续集成CI/CD

一、持续集成(Continuous Integration)

持续集成是一种软件开发实践,即团队开发成员经常集成他们的工作,通常每个成员每天至少集成一次,也就意味着每天可能会发生多次集成。每次集成都通过自动化的构建(包括编译,发布,自动化测试)来验证,从而尽快地发现集成错误。许多团队发现这个过程可以大大减少集成的问题,让团队能够更快的开发内聚的软件。 看完这段话,估计还是有点懵。怎么理解呢?我是这样理解的: 软件集成是软件开发过程中的一个环节,这个环节的工作一般会包括以下流程:合并代码---->安装依赖---->编译---->测试---->发布。软件集成的工作一般会比较细碎繁琐,为了不影响开发效率,以前软件集成这个环节一般不会经常进行或者只会等到项目后期再进行。但是有些问题,如果等到后期才发现,解决问题的代价很大,有可能导致项目延期或者失败。因此,为了尽早发现软件集成错误,鼓励团队成员应该经常集成他们的工作,通常每个成员每天应该至少集成一次。这就是所说的持续集成。所以说,持续集成是一种软件开发实践。 软件集成的工作细碎繁琐,以前是由人工完成的。但是现在鼓励持续集成,那岂不是要累死人,还影响开发效率。所以,应该考虑将软件集成这个工作自动化,这就出现了所谓的持续集成系统。

二、GitLab-CI GitLab-CI就是一套配合GitLab使用的持续集成系统(当然,还有其它的持续集成系统,同样可以配合GitLab使用,比如Jenkins)。而且GitLab8.0以后的版本是默认集成了GitLab-CI并且默认启用的。 三、GitLab-Runner 那GitLab-Runner又是什么东东呢?与GitLab-CI有什么关系呢? GitLab-Runner是配合GitLab-CI进行使用的。一般地,GitLab里面的每一个工程都会定义一个属于这个工程的软件集成脚本,用来自动化地完成一些软件集成工作。当这个工程的仓库代码发生变动时,比如有人push了代码,GitLab就会将这个变动通知GitLab-CI。这时GitLab-CI会找出与这个工程相关联的Runner,并通知这些Runner把代码更新到本地并执行预定义好的执行脚本。 所以,GitLab-Runner就是一个用来执行软件集成脚本的东西。你可以想象一下:Runner就像一个个的工人,而GitLab-CI就是这些工人的一个管理中心,所有工人都要在GitLab-CI里面登记注册,并且表明自己是为哪个工程服务的。当相应的工程发生变化时,GitLab-CI就会通知相应的工人执行软件集成脚本。如下图所示:

GitLab-CI与GitLab-Runner关系示意图 Runner可以分布在不同的主机上,同一个主机上也可以有多个Runner。 Runner类型 GitLab-Runner可以分类两种类型:Shared Runner(共享型)和Specific Runner(指定型)。 Shared Runner:这种Runner(工人)是所有工程都能够用的。只有系统管理员能够创建Shared Runner。 Specific Runner:这种Runner(工人)只能为指定的工程服务。拥有该工程访问权限的人都能够为该工程创建Shared Runner。

CI/CD  持续交付/持续部署

持续交付(Continuous delivery)指的是,频繁地将软件的新版本,交付给质量团队或者用户,以供评审。如果评审通过,代码就进入生产阶段。 持续部署(continuous deployment)是持续交付的下一步,指的是代码通过评审以后,自动部署到生产环境。

按照我的理解,每个项目里面定义了.gitlab-ci.yml(CI脚本)

每一次代码提交更改,都会触发CI

CI里面定义的任务,任务由Runner来完成

Runner执行这些shell命令,需要由docker来完成

注意:docker镜像必须要安装指定的命令,才能执行脚本。比如rsync

gitlab的安装,请参考链接

http://www.py3study.com/Article/details/id/104.html

下一篇文章,我来介绍一下gitlab-ci.yml脚本如和编写

http://www.py3study.com/Article/details/id/140.html

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏JAVA技术zhai

大话微服务架构的故障隔离及容错处理机制

8、限流器和负载开关(Rate Limiters and Load Shedders)

32220
来自专栏张善友的专栏

K2 Blackpearl的Outcomes Actions和Line Rule

使用K2 blackpearl设计流程的时候有两个重要概念是Outcomes和Actions。 ? Actions代表的是人与工作流交互的时候,对流程处理的...

19970
来自专栏跨界架构师

做了「负载均衡」就可以随便加机器了吗?这三招来帮你!

        这篇是《分布式关注点系列》中「负载均衡」相关的内容最后一发了,后续也会继续讲「高可用」相关的其它主题,主要是限流、降级、熔断之类的吧,具体还没定...

18930
来自专栏Java进阶架构师

【架构技术专题】什么是架构设计的五个核心指标?如何设计?(4)

性能就是核心要素之一,不然我为什么架构设计?随随便便一个lowlow的系统上线就好了。所以性能优化是很多小公司卖不去过的坎。这么说吧,当然优化网站性能的手段也非...

30840
来自专栏EAWorld

DevOps平台实践落地之构建管理详解

? 企业做DevOps平台,本质上是做企业的IT生产线,最终是实现整个企业级的数字化生产线。构建作为落地DevOps平台必不可少的环节之一,是持续集成、交付和...

587100
来自专栏Java架构师学习

深入理解大型网站架构的核心——了解性能

18230
来自专栏嵌入式程序猿

这个坑希望你没踩

最近因为一个小项目使用KE02来评估,用的是FRDM-KE02Z的板子,但是在将新买的板子连上电脑后,始终连不上目标板,而电脑可以正常连接其他板子,所以证明驱动...

12620
来自专栏Keegan小钢

App架构设计经验谈:数据层的设计

一个App,从根本上来说,就是对数据的处理,包括数据从哪里来、数据如何组织、数据怎么展示,从职责上划分就是:数据管理、数据加工、数据展示。相对应的也就有了三层架...

14420
来自专栏FD的专栏

【架构拾集】 微前端:微应用化

微应用化与微前端架构相当的类似,它们在开发时都是独立应用,在构建时又可以按照需求单独加载。如果以微前端的单独开发、单独部署、运行时聚合的基本思想来看,微应用化就...

12630
来自专栏纯洁的微笑

几种分布式调用链监控组件的实践与比较(二)比较

引言:继上篇《几种分布式调用链监控组件的实践与比较(一)实践》后,本篇将会讲下几种APM选型的比较与性能测试。

32320

扫码关注云+社区

领取腾讯云代金券