Buildbot entry-Introduction

I. Introduction

1. buildbot is an open-source python-based continuous integration system. It can trigger the corresponding automatic build and test run in the following three ways to quickly discover problems, at the same time, it is pointed out that the developer who caused this error, of course, we can also intuitively understand all the tasks currently bound to the master and various testing statuses through the page.

1)Monitor changes in the Code Management LibraryThis triggers the build test task.

2) ConfigureTimingTrigger build test task

3) allowForceTrigger build test task

2. It has many advantages:

1)Cross-platform: It can run on various platforms for testing on different platforms

2)It can process programs written in various languagesSuch as C, Java, and Python

3)Low environment requirements and simple configuration: Python and Twisted

4)Multiple delivery methods of resultsSuch as Email, webpage, IRC, or other protocol tools

5)Inherit and override the parent class through subclass to flexibly configure

6)Distributed deployment and integration are well implemented.

Therefore, many large companies are currently using this system, such

1) chrome: https://chromium-build.appspot.com/p/chromium/console

2) webkit: http://build.webkit.org/waterfall

Ii. Basic system principles 1. Overall system architecture

Buildbot is mainly composed of one buildbot-master and one or more buildbot-slave connected by a star structure in the network topology,

The following figure shows the functions of each part.

1)Repository:Code Management Library for code management and version control developed by teams. Currently, svn, cvs, git, and so on are popular ......

2)Buildmaster:It is mainly responsible for assigning and telling slave when to perform the test, how to perform the test, and what kind of test can be said to be a decision center, and the core of this decision center is the master. cfg is a configuration file written in python syntax (the configuration file will be explained later ).

3)Buildslave:Executes the test based on the Command issued by buildmaster, and returns the execution status and result to buildmaster.

4)Notifiers:When BuildMaster receives the execution result of BuildSlave, it triggers Notifiers and delivers the result according to the configuration method.

2. communications between BuildSlave, BuildMaster, and Repository

1) BuildSlave usually runs on one or more independent machines. These machines can have different systems, depending on your interests and needs. Then. Of course, these machines and buildmaster or Repository do not have to be directly connected. There may be some simple firewall machines in the middle, as long as the communication between builslave and buildmaster and Repository is not blocked.

2) The TCP connections between the three are actively initiated by BuildSlave.

3) All commands can only be delivered to BuildSlave by BuildMaster, and both the Command issued by BuildMaster and the result Uploaded By BuildSlave are transmitted through a TCP connection.

4) BuildMaster does not provide source code. Therefore, BuildSlave must be able to connect to Repository for relevant operations when the source code is required.

2. BuildMaster Architecture

Buildmaster consists of the following four parts. Assume that our Repository is VC Repository:

Next we will briefly introduce the usage of each part above,

ChangeSources:The trigger source of schedory. Whenever the VC Repository changes, a Change object is created and submitted to each schedory.

Schedulers:The schedue will collect the Changes submitted by ChangeSources to BuildRequests. When the Builder is available, the changes will be queued and delivered to Builders as Queue.

Builder:Decides how to execute the build and test tasks, each of which runs only on one machine

SlaveBuilder:Multiple

Status plugins:Plug-ins used to deliver build results

),

2. BuildMaster ArchitectureIn the figure in this chapter, we can also see the entire control process of BuildBot.

Notify corresponding developers. Of course, we can also configure to notify corresponding developers only when the operation fails.

Therefore, each Status plugin has a reference pointing to the core Status object in the top layer of the graph, so that you can obtain information about every Builder, build, Step, and even log file. In addition, when a new Build is created, the Status can also monitor the new Build through the core Status object.