buildbot入门系列—介绍篇
添加时间:2013-8-7 点击量:
一、介绍
1. buildbot是一个开源的基于python的连气儿集成体系，它可以或许以下三种体式格式触发响应的主动构建和测试运行，从而敏捷的发明题目地点，同时指出造成这个错误的开辟人员，当然我们还可以经由过程页面直观的懂得到当前所有和master绑定的任务以及各类测试状况。
1） 监控代码经管库的变更从而触发构建测试任务
2） 经由过程设备从而按时触发构建测试任务
3） 经由过程设备从而容许强迫触发构建测试任务
2. 因为它有很多斗劲好的特点：
1） 跨平台：可以运行在各类平台上，实现不合平台上的测试
2） 可以处理惩罚各类说话编写的法度，例如C，Java，Python
3） 景象请求低并且设备简单：仅仅须要Python，和收集库Twisted
4） 成果的交付体式格式多，例如Email，webpage，IRC或者其他和谈对象
5） 经由过程子类持续并重写父类从而灵活的设备
6） 很好的实现了分布式安排和集成工作
所以今朝有很多大公司都在应用这个体系，比如
1） chrome : https://chromium-build.appspot.com/p/chromium/console
2） webkit : http://build.webkit.org/waterfall
二、体系基起原根蒂根基理
1.体系整体架构
buildbot首要由一个buildbot-master和一个或者多个buildbot-slave两项目组经由过程收集拓扑布局中的星型布局连接而成，如图：
重视：因为汗青原因，很多景象下，我们都直接称buildmaster为buildbot，而buildslave称呼不变。
下面我们经由过程上方这幅图来具体懂得下各项目组的感化吧。
1） Repository ：代码经管库，用于团队开辟的代码经管和版本把握，今朝风行的有svn，cvs，git……
2） Buildmaster：首要负责分派并且告诉slave什么时辰进行测试，如何进行测试，进行什么样的测试，可以说是一个决定计划中间，而这个决定计划中间的核心在于master.cfg这个设备文件，它其实是一个用python语法来写的设备文件（设备文件后期会进行讲解）。
3） Buildslave : 负责按照buildmaster下发的Command号令履行测试，同时将履行状况和成果返回给buildmaster
4） Notifiers ：当BuildMaster接管到BuildSlave的履行成果后触发Notifiers，按照设备的体式格式将成果交付。
2.BuildSlave、BuildMaster、Repository间的通信
1） BuildSlave凡是运行在一台或者多台不合的自力的机械中，这些机械可以有不一样的体系，具体按照你的爱好和需求而定。然后这些BuildSlave机械都是经由过程TCP连接到BuildMaster机械的公共端口进行通信的。当然这些机械和buildmaster或者Repository之间不必然必须直接相连，中心可以有一些简单的防火墙机械，只要不故障builslave和buildmaster、Repository之间的通信即可。
2） 他们三者间的TCP连接，都是由BuildSlave主动创议的
3） 所有的号令都只能由BuildMaster下发到BuildSlave，并且不管是BuildMaster下发的号令，还是BuildSlave上传的成果都是经由过程TCP连接进行传输的
4） BuildMaster并不供给源代码，是以BuildSlave须要源代码的时辰必须可以或许连接到Repository 进行响应操纵。
2.BuildMaster的架构
Buildmaster由以下四大项目组构成，如图，假设我们的Repository是VC Repository:
下面我们来简单介绍下上方的每个项目组的用处，这些在master.cfg中都可以或许进行设备的：
1） ChangeSources：Scheduler的触来源，每当VC Repository产生了变革，就会创建一个Change对象提交给各个Scheduler
2） Schedulers : 决意什么时辰进行构建和测试任务，该Scheduler将会收集ChangeSources提交过来的Changes到BuildRequests中，当BuilderSlave可用时，就将这些changes列队成Queue交付给Builders
3） Builder ：决意如何履行构建和测试任务，每一个Build只运行在一部机械中
4） SlaveBuilder : 多个SlaveBuilder构成一个BuildSlave。
5） Status plugins：用于交付构建成果的插件
从图中我们还可以看出（重视BuildSlave和SlaveBuild是不一样的哦），
1） 每一个Builder是由一些列与他的构建任务相干的BuilderSlave构成的。这些BuilderSlave的地位是一律的，这么做的原因只是为了负载均衡
2） Builder将会在与它相接洽关系的BuilderSlave中创建一到多个SlaveBilder，这些SlaveBuilder是自力运行在不一样的文件夹中。
3） 多个Builder可以共享一个BuildSlave。
3.Buildbot的把握流程
从2.BuildMaster的架构章节中的那幅图中，我们还可以看出BuildBot的全部把握流程。
1） 有这么一个开辟人员，提交了一些批改了的代码到Repository 中，然后builbot中的相干脚本监控到了就经由过程Email或者收集连接将这些改变信息发送给了buildmaster，信息中包含了谁导致了这些变革，哪些文件被批改了，包含这些改变的版本以及一些其他的注释。
2） buildmaster分派这些改变到不合的Scheduler，一些响应有设备的改变将会触发tree-stable-timer开端策画，同时该改变被添加到一个新的Build中，当tree-stable-timer到了有效期，该Build将会被添加到一个Builder中并且运行在一个BuildSlave中，当然这个Builder中的所有Build构建运行测试任务用的都是同一版本的源代码。
3） 这些Build又是由一系列的步调Step构成的。每个Step都邑包含一条甚至多条将会在BuildSlave机械中运行的号令。一般景象下，第一个Step都是从Repository中导出源代码。接下来的一般都是进行编译或者单位测试的。在履行过程中，所有的Setp都邑将它们自身履行号令的成果以及状况返回给buildmaster。
4） 当这些Build运行的时辰，它们会将响应的如Build Started， Step Started， Build Finished这些号令打印到所有的状况终端中。比如我们常见的waterfall。
5） 当一个 MailNotifier 状况终端被激活的时辰，一个build完成之后都邑发送一封email通知响应的开辟人员。当然我们也可以设备当且仅当运行失败的时辰才通知响应的开辟人员。
4.状况交付架构
BuildMaster保持着一个核心的Status对象，这个核心的Status对象连接着很多Status plugin，经由过程这个核心对象，我们可以获取到每一层的所有构建状况对象，如图：
是以，每一个Status plugin都有一个引用指向图中最顶层的那个核心Status对象，从而可以获取到每一个Builder、build，Step甚至日记文件的信息。除此之外，当有新的Build创建时，Status还可以经由过程核心Status对象去新的Build。
真正的心灵世界会告诉你根本看不见的东西，这东西需要你付出思想和灵魂的劳动去获取，然后它会照亮你的生命，永远照亮你的生命。——王安忆《小说家的十三堂课》
一、介绍
1. buildbot是一个开源的基于python的连气儿集成体系，它可以或许以下三种体式格式触发响应的主动构建和测试运行，从而敏捷的发明题目地点，同时指出造成这个错误的开辟人员，当然我们还可以经由过程页面直观的懂得到当前所有和master绑定的任务以及各类测试状况。
1） 监控代码经管库的变更从而触发构建测试任务
2） 经由过程设备从而按时触发构建测试任务
3） 经由过程设备从而容许强迫触发构建测试任务
2. 因为它有很多斗劲好的特点：
1） 跨平台：可以运行在各类平台上，实现不合平台上的测试
2） 可以处理惩罚各类说话编写的法度，例如C，Java，Python
3） 景象请求低并且设备简单：仅仅须要Python，和收集库Twisted
4） 成果的交付体式格式多，例如Email，webpage，IRC或者其他和谈对象
5） 经由过程子类持续并重写父类从而灵活的设备
6） 很好的实现了分布式安排和集成工作
所以今朝有很多大公司都在应用这个体系，比如
1） chrome : https://chromium-build.appspot.com/p/chromium/console
2） webkit : http://build.webkit.org/waterfall
二、体系基起原根蒂根基理
1.体系整体架构
buildbot首要由一个buildbot-master和一个或者多个buildbot-slave两项目组经由过程收集拓扑布局中的星型布局连接而成，如图：
重视：因为汗青原因，很多景象下，我们都直接称buildmaster为buildbot，而buildslave称呼不变。
下面我们经由过程上方这幅图来具体懂得下各项目组的感化吧。
1） Repository ：代码经管库，用于团队开辟的代码经管和版本把握，今朝风行的有svn，cvs，git……
2） Buildmaster：首要负责分派并且告诉slave什么时辰进行测试，如何进行测试，进行什么样的测试，可以说是一个决定计划中间，而这个决定计划中间的核心在于master.cfg这个设备文件，它其实是一个用python语法来写的设备文件（设备文件后期会进行讲解）。
3） Buildslave : 负责按照buildmaster下发的Command号令履行测试，同时将履行状况和成果返回给buildmaster
4） Notifiers ：当BuildMaster接管到BuildSlave的履行成果后触发Notifiers，按照设备的体式格式将成果交付。
2.BuildSlave、BuildMaster、Repository间的通信
1） BuildSlave凡是运行在一台或者多台不合的自力的机械中，这些机械可以有不一样的体系，具体按照你的爱好和需求而定。然后这些BuildSlave机械都是经由过程TCP连接到BuildMaster机械的公共端口进行通信的。当然这些机械和buildmaster或者Repository之间不必然必须直接相连，中心可以有一些简单的防火墙机械，只要不故障builslave和buildmaster、Repository之间的通信即可。
2） 他们三者间的TCP连接，都是由BuildSlave主动创议的
3） 所有的号令都只能由BuildMaster下发到BuildSlave，并且不管是BuildMaster下发的号令，还是BuildSlave上传的成果都是经由过程TCP连接进行传输的
4） BuildMaster并不供给源代码，是以BuildSlave须要源代码的时辰必须可以或许连接到Repository 进行响应操纵。
2.BuildMaster的架构
Buildmaster由以下四大项目组构成，如图，假设我们的Repository是VC Repository:
下面我们来简单介绍下上方的每个项目组的用处，这些在master.cfg中都可以或许进行设备的：
1） ChangeSources：Scheduler的触来源，每当VC Repository产生了变革，就会创建一个Change对象提交给各个Scheduler
2） Schedulers : 决意什么时辰进行构建和测试任务，该Scheduler将会收集ChangeSources提交过来的Changes到BuildRequests中，当BuilderSlave可用时，就将这些changes列队成Queue交付给Builders
3） Builder ：决意如何履行构建和测试任务，每一个Build只运行在一部机械中
4） SlaveBuilder : 多个SlaveBuilder构成一个BuildSlave。
5） Status plugins：用于交付构建成果的插件
从图中我们还可以看出（重视BuildSlave和SlaveBuild是不一样的哦），
1） 每一个Builder是由一些列与他的构建任务相干的BuilderSlave构成的。这些BuilderSlave的地位是一律的，这么做的原因只是为了负载均衡
2） Builder将会在与它相接洽关系的BuilderSlave中创建一到多个SlaveBilder，这些SlaveBuilder是自力运行在不一样的文件夹中。
3） 多个Builder可以共享一个BuildSlave。
3.Buildbot的把握流程
从2.BuildMaster的架构章节中的那幅图中，我们还可以看出BuildBot的全部把握流程。
1） 有这么一个开辟人员，提交了一些批改了的代码到Repository 中，然后builbot中的相干脚本监控到了就经由过程Email或者收集连接将这些改变信息发送给了buildmaster，信息中包含了谁导致了这些变革，哪些文件被批改了，包含这些改变的版本以及一些其他的注释。
2） buildmaster分派这些改变到不合的Scheduler，一些响应有设备的改变将会触发tree-stable-timer开端策画，同时该改变被添加到一个新的Build中，当tree-stable-timer到了有效期，该Build将会被添加到一个Builder中并且运行在一个BuildSlave中，当然这个Builder中的所有Build构建运行测试任务用的都是同一版本的源代码。
3） 这些Build又是由一系列的步调Step构成的。每个Step都邑包含一条甚至多条将会在BuildSlave机械中运行的号令。一般景象下，第一个Step都是从Repository中导出源代码。接下来的一般都是进行编译或者单位测试的。在履行过程中，所有的Setp都邑将它们自身履行号令的成果以及状况返回给buildmaster。
4） 当这些Build运行的时辰，它们会将响应的如Build Started， Step Started， Build Finished这些号令打印到所有的状况终端中。比如我们常见的waterfall。
5） 当一个 MailNotifier 状况终端被激活的时辰，一个build完成之后都邑发送一封email通知响应的开辟人员。当然我们也可以设备当且仅当运行失败的时辰才通知响应的开辟人员。
4.状况交付架构
BuildMaster保持着一个核心的Status对象，这个核心的Status对象连接着很多Status plugin，经由过程这个核心对象，我们可以获取到每一层的所有构建状况对象，如图：
是以，每一个Status plugin都有一个引用指向图中最顶层的那个核心Status对象，从而可以获取到每一个Builder、build，Step甚至日记文件的信息。除此之外，当有新的Build创建时，Status还可以经由过程核心Status对象去新的Build。
真正的心灵世界会告诉你根本看不见的东西，这东西需要你付出思想和灵魂的劳动去获取，然后它会照亮你的生命，永远照亮你的生命。——王安忆《小说家的十三堂课》
