Continuous Integration with buildbot: why?

In the last post I wanted to introduce the buildbot. But the topic was not fully disclosed by me.

Today I will try to catch up a little.

What for?

If you have a large and complex project, then most likely no single continuous integration system out of the box will give you what you want. And here everyone gets out as they can: someone writes plugins, someone makes crutches. And, alas, the second option is quite common. This may be due to the fact that the selected CI system does not have sufficient flexibility.

What does buildbot give us?

• All python's expressive power in the build config
• Once the config is a code, then we can put it in git
• Well, you can fasten the review code to the gita
• Assembly schedule, associated launch
• Supports all modern VCS
• You can do everything the way you want
• JSON api

')

And what are the disadvantages?

• No beautiful buttons (yet)
• Setting is nontrivial
• Documentation so-so
• There is almost no Russian-speaking community.
• Write a lot yourself

Examples

Since we put flexibility at the head of the table, it would be good to see clear evidence of it.

We generate assemblies

If your project is going under different platforms, then writing a new config will be a routine for each build.

From this we can in a couple of lines generate the number of assemblies we need from the input parameters.

This is how the assemblies of earlier versions of CyanogenMod were generated.

Self-renewal

A good practice would be to put all the configs of your master server in git and instruct the buildbot to update itself.

Then the probability that you accidentally break something will decrease, especially if you use the practice of code review in your company.

This is done approximately as follows:

• We put next to the master new slave
• We create a builder and instruct him to keep track of the repository in which our configs are located.
• If something new appears in the repository, then we take the changes and reconfigure the wizard

The implementation of such a scheme can be found here .

Divide and rule

In my opinion, storing configs of all assemblies in one file is very inconvenient. But every time to climb in to edit the master config, to add a new import to it, too, does not deliver joy.

For myself, I wrote the following implementation of the loader, which automatically picks up configs from a specific folder.

Conclusion

Most likely this is not enough to get interested in the buildbot. From that, I strongly recommend to visit the project site and see the list of success stories .



And if for any reason you are not satisfied with your current system of continuous integration, then I suggest paying attention to buildbot. For me it is so worth it.

I am pleased to answer questions.