关于我们

质量为本、客户为根、勇于拼搏、务实创新

< 返回新闻公共列表

持续集成服务器部署策略

发布时间:2019-07-17 18:11:47

在软件托付范畴上有一个十分有用的启示式准绳:提早并频繁地做让你感到痛苦的事。集成通常是一个十分痛苦的过程,所以每次有人提交代码后应立即停止集成。

 马丁福勒说:持续集成是一种软件开发理论,即团队开发成员经常集成他们的工作,经过每个成员每天至少集成一次,也就意味着每天可能会发作屡次集成。每次集成都经过自动化的构建(包括编译,发布,自动化测试)来考证,从而尽早地发现集成错误。

而持续集成效劳器(也称为构建效劳器,又称CI效劳器)是一种软件工具,它包含一切持续集成操作,并为我们构建项目提供牢靠和稳定的环境。

工欲善其事,必先利其器。持续集成的重要性无须置疑,但是了解如何创立平安、高效、可伸缩的持续集成效劳器将使得持续集成愈加顺畅。

CI效劳器 - 装置方式

CI效劳器的装置方式有四种:

  • 单机
    单机的CI效劳器即装置在一台单个主机上,通常用于小型项目。

  • 托管
    托管的CI效劳器由托管平台提供,普通是依据订阅计价。这普通被那些不想维护CI效劳器的企业所采用。

  • 私有云
    一些大型企业或者想要完整掌控及平安运用他们本人的根底设备的组织,通常会选择私有云的部署方式。

  • 半托管半私有云
    这种方式是对托管部署和私有云部署的折中计划。这种部署方式通常将流水线管理,日志管理,用户管理局部停止托管,而将流水线运转时环境放在私有云中。这种方式即保证了根底设备平安,同时也降低了维护CI效劳器的本钱。

我所在的团队最初运用私有云的方式搭建CI效劳器,但出于可维护性、本钱和平安性等方面的折中思索转向了半托管半私有云的装置方式。本文将主要讨论在私有云和半托管半私有云装置方式下CI效劳器的部署战略。

CI效劳器 - 主从架构

主从架构也叫主仆架构或者Master-Slave架构,主从式架构企图提供一个可伸缩的架构,其中心是基于分而治之的思想,将一个原始任务合成为若干个子任务,并由特地的工作者来执行这些任务,原始任务的结经过整合各个子任务的处置结果构成。

主从架构看似与CI效劳器毫无关系,实则联络严密。由于很多CI效劳器运用了主从架构或者效劳器/代理架构。经过主从架构的Master能够停止用户管理、流水线管理、日志管理。Master作为任务调度者,给多个主从架构的Slave分配任务,Slave会将流水线任务运转的信息和结果发给Master。主从架构提供了一个可伸缩的架构,所以能够动态的添加或者删除Slave以支持团队动态变化的持续集成任务。

CI效劳器 - 部署战略

通常,一个开发团队会有三个应用部署环境:开发环境(Dev),类消费环境(Staging)和消费环境(Production)。当一次修正经过持续集成后,就会被部署到开发环境,然后部署到类消费环境,然后部署到消费环境。

为此,需求CI效劳用具有操作相应部署环境的权限。如图2,开发环境中部署了CI效劳器,其中每个CI效劳器都具有开发、类消费和消费环境的权限。



这种方式粗暴简单,看似药到病除本质上却会引发很严重的平安问题。通常项目中对开发、类消费和消费环境权限的管控相似于金字塔,越往上权限管控越严厉。但假如开发环境的CI效劳器也具有类消费和消费环境的权限,那么这座原本巩固的金字塔将有可能霎时崩塌。

为理解决开发环境CI效劳用具有多环境操作权限的问题,如图3所示,能够在不同的环境独立部署一套CI效劳器,这样部署某个环境时,就能够运用相应环境的CI效劳器即可。


但随之而来的问题是,不同的环境独立部署一套CI效劳器,会使得每个环境的CI效劳器之间没有任何关系。它们的流水线管理,日志管理,用户管理都是独立的。这意味着本来一个流水线完成的事情会分散的对个多个持续集成系统中,用户需求在多个系统中来回切换。这不只降低了运用体验,并且增加了复杂性和维护本钱。

那么有没有什么方法,既保证只部署一套CI效劳器,同时又能保证CI效劳器不能跨环境操作?如图4所示,固然一切的CI效劳器仍然部署在开发环境中,但每个CI效劳器代理曾经被打上了开发环境、类消费和消费环境的标签,并且只具有操作相应环境的权限。



/template/Home/Zkeys/PC/Static