buildbot一：介绍

buildbot是一个开源的基于Python的持续集成系统，即自动化软件构建，测试，发布流程的框架。

它以以下三种方式触发相应的自动构建和测试运行，从而迅速的发现问题所在：

1. 监控代码管理库的变化从而触发构建测试任务
2. 通过配置从而定时触发构建测试任务
3. 通过配置从而允许强制触发构建测试任务

自动化构建：一般包括自动下载源码，编译，测试，打包
buildbot优点：
1.夸平台：可以运行在各种平台上，实现不同平台的测试
2.可以处理各种语言编写的程序，比如：c，java，python等
3.环境要求低并且配置简单：仅仅需要Python，和网络库Twisted
4.结果的交付方式多，例如Email，webpage，IRC或者其他协议工具
5.通过子类继承并重写父类从而灵活的配置
6.很好的实现了分布式部署和集成工作
buildbot系统架构：
Buildbot包含一个服务端，一个或多个客户端。以星形拓扑结构连接。

需要配合GIT,SVN,CVS等相关版本工具使用。

master可以给任意一个slave发送命令，slave执行master发送的命令并返回执行的结果。
注意：来回发送大量命令是不太合适的，可以在slave中写出一个总的执行脚本，而master发送的命令只是启动这个脚本。
Buildbot的原理，是git，SVN等源码服务器上代码发生变化后，buildmaster（服务端）通知连接到它上的buildslave（客户端）从git或SVN服务器上自动下载源码，编译，测试，打包。最后把各个buildslave的自动化构建的结果搜集起来在web上展现，或通过email,IRC等方式通知相应的项目开发人员。
buildbot测试状态结构体系：
master有一个总的status对象负责监控所有连接到自己的slave的连接状态对象，通过这个连接对象获得完整构建的状态及层次结构。

每一次的项目构建都可以产生一个status对象，可以通过MailNotifier每一次构建都建立一个邮件列表。

Buildbot使用的是典型的Master-Slave架构，按照节点的角色分类，可以分为

• Buildbot-master：负责处理仓库的变动，通知以及向Buildbot-worker发送命令。
• Buildbot-worker：负责具体的代码拉取，构建和测试等操作。

几个更细粒度的概念：

• Scheduler：接收代码变动的通知，向Builder队列发送build请求，Buildbot具备不同类型的Scheduler，例如针对特定分支的SingleBranchScheduler，手动触发的ForceScheduler等。
• Builder：负责向Worker分发任务，可以关联多个Worker，但每次build只能在一个Worker上执行。
• Worker：对应Buildbot-worker，可以对应多个Builder。

Builder和Worker之间是多对多的关系：

• 多个Worker对于单个Builder而言，相当于是一个Worker Pool，这样就能够避免在几个Worker offline后，导致该Builder无法执行构建操作的情况。
• 单个Worker能够对应多个Builder，是因为每个Worker其实可以包含多个tag信息，而每个tag都可能对应一个Builder。

关于Master-Slave架构的单点故障问题，Buildbot也有具体的解决方案

 

buildbot与jenkins的区别：

与Jenkins相比，Buildbot在大陆使用者较少。

原因在于Jenkins的界面相对较美观，更容易上手；Jenkins的中文文档比较丰富。但是Jenkins因为资源消耗庞大、不太方便定制而不受一些有实力的公司欢迎。这些不少把目光聚焦在Buildbot。

究竟Buildbot有哪些优点让这些公司青睐呢？

Buildbot基于python网络框架Twisted，分布式做得好。

Buildbot可以直接使用python包，轻松拥有上万库，具备强大的扩展能力。

如果你觉得Jenkins已经轻松地满足你的需求，你不需要Buildbot。

如果你在Jenkins时觉得效率低下、扩展困难、一些用python等脚本可以实现的动作在Jenkins困难重重，那么可以看看Buildbot。

 

CI与CD的区别：

CI：continuous integration，持续集成。

开发人员会频繁的提交代码到主干，这些提交在最终合并到主线之前，都需要编译和自动化测试进行验证。

代码持续集成很重视自动化测试验证结果，以保障所有的提交在合并到主线之后的质量问题，对可能出现的一些问题进行预警。

CD：continuous delivery，持续交付。

持续交付，就是应用发布出去的过程。这个过程可以确保我们尽可能快的实现交付。这意味着除了自动化测试，我们还需要自动化发布流，以及通过一个按键就可可以随时随地实现应用的部署上线。

通过持续交付，你可以决定每天，每周，每两周发布一次，这完全可以根据自己的业务进行设置。

如果你希望体验持续交付的优势，需要先进行小批量的发布，尽快部署到生产线，以便在出现问题时方便进行故障排除。

CD：continuous deployment，持续部署。

如果想更深入一步的话，就是持续部署。

通过这个方式，任何修改通过了所有已有的工作流就会直接和客户见面。

没有人为干预（没有一键部署按钮），只有当一个修改在工作流中，构建才能阻止它部署到产品线。

持续部署是一个很优秀的方式，可以加速与客户的反馈循环，但是会给团队带来压力。

因为不再有“发布日”了，开发人员可以专注于构建软件，他们的修改，在他们完成工作后几分钟就上线了。

基本上，当开发人员在主分支中合并一个提交时，这个分支就被构建、测试，如果顺利，则部署到生产环境中。

 

持续集成需要具备的条件：

• 需要为每个新功能、代码改进、bug修复，创建自动化测试用例
• 需要一个持续集成服务器，它可以监控代码提交情况。对每个新的提交进行自动化测试。
• 研发团队需要尽可能快的提交代码，至少每天提交一次。

持续集成的优势：

• 通过自动化测试，可以提早拿到回归测试的结果，避免将一些问题提交到交付生产中。
• 发布编译更容易，因为合并之初已经将所有问题都规避了。
• 减少工作问题切换，研发可以很快获得构建失败的消息，在开始下一个任务之前就可以很快解决。
• 测试成本大幅降低，你的CI服务器可以在几秒钟内运行上百条测试。
• 你的QA团队花费在测试上面的时间会大幅缩短，将会更加侧重于质量上的提升。

持续交付需要具备什么条件：

• 需要有强大的持续集成组件和足够多的测试项，可以满足你代码的需求
• 部署需要自动化。
• 触发是手动的，但是部署一旦开始，就不能人为干预
• 你的团队可能需要接受特性开关，没有完成的功能模块不会影响到线上产品

持续交付的优势：

• 繁琐的部署工作没有了。你的团队不需要花费几天的时间去准备一个发布。
• 可以更快的进行交付，加快了与客户之间的反馈环。
• 轻松应对小变更，加速迭代

持续部署需要具备什么条件：

• 研发团队测试理论比较完善。
• 测试单元的健壮性直接决定你的交付质量。
• 你的文档和部署频率要保持一致
• 特征标志成为发布重大变化过程中的固有部分，以确保你可以与其它 部门协调。

持续部署的优势：

• 发布频率更快，因为你不需要停下来等待发布。每一处提交，都会自动触发发布流。
• 在小批量发布的时侯，风险降低了，发现问题也可以很轻松的修复。
• 客户每天都可以看到我们的技续改进和提升，而不是每个月、或季度，或年。