This article comes from: http://doc.chinaunix.net/python/201006/683326.shtml
Continuous Integration (CI) is to carry forward the following principles of a software development process:
Maintaining single-source repository
Automated build process
To achieve self-test build
Everyone has a contribution every day
Each contribution will be applied to construction of the main line on an integrated machine
Accelerate the construction process
The same test is performed in a production environment
So that anyone can easily obtain the latest executable file
Everyone can see the current situation
Automated Deployment
By Martin Fowler strong popularity, the basic concept of CI is to continue to build and test the software program and each branch will merge branch code. This can improve the health of the code base as a whole. You can also increase communication with team members, and the opportunity to get feedback on the overall quality of the code. People often use this cycle to generate code coverage reports and other statistics.
Buildbot similar to other CI systems to help automate this check, build and test processes. Buildbot slaves typically run on different platforms, such as Win32, Solaris, Intelx64 and so on. When a build (build) interrupts, Buildbot can send an e-mail notification, build it all running track, so developers overlooking the entire process. Finally, people often use automated metrics within a given period of time to build software quality. This article will talk about the end of the metrics and run their causes within a CI system.
About Buildbot
Before we dive explore Buildbot, look at its structure. 1, at the top of the build process has three main layers. The first is a version of the control layer, it notifies the hook from a version control system. Followed by a buildup layer, where it acquires the communication from the primary server to build, and returns the results to build. Finally, a layer of notification for sending e-mail or fail when building an IRC message, or make a web page displays the cumulative results build.
Figure 1. Buildbot Architecture Overview
View Original (larger image)
One of the central characteristics Buildbot architecture is based on the dependence Twisted Python library for processing asynchronous communication master (master) and servo (slave) between. The callback-based architecture supports a very simple, but robust master / servo feedback loop.
If you have not heard of Buildbot, a search on Google you will find a lot of open source projects related to the size of the primary server and servo. About Servo, I briefly mentioned a little earlier, on the original meaning of the servo machine which is controlled by a master Buildbot server. In general, a servo operation is one of several different test platforms servo. This is Buildbot server in a very important concept. For example, you may be on the mailing list of an open source project, I heard someone say, "Some people volunteer to act as servo Windows virtual machine do?"
Python language project itself uses a lot Buildbot servo, continuous build and test the latest version of Python on as many platforms. Figure 2 shows the running Python and the backbone of many servo test. With the development of virtualization technology, now often requires the development of community members hosted a Buildbot servo machine, or just run the simulation several different hardware configurations of virtual machines.
FIG 2. Python Buildbot;
View Original (larger image)
Another high-profile Buildbot user is Google Chrome browser project. Figure 3 shows a highly customized Buildbot, which greatly enhances the appearance of the user interface Buildbot. Fortunately, Google will provide these enhancements to the open source Buildbot.
Figure 3. Google Chrome enhanced Buildbot;
View Original (larger image)
Construction of this configuration is not within the scope of this article, but I recommend that you look at yourself. Now we look at how to make a Buildbot master server up and running quickly.
Set 5 minutes Buildbot
I performed it a few steps on Ubuntu 8.10, but they should apply on most Linux systems:
下载 ez_setup.py：
wget http://peak.telecommunity.com/dist/ez_setup.py
安装 easy_install：
sudo python ez_setup.py
使用 apt-get 安装 Python Twisted 包
sudo apt-get install python-Twisted
遵循这个 collective.buildbot “秘诀”：
sudo easy_install collective.buildbot
此时，许多东西开始涌出 shell，因为有一大堆包被下载且得到自动安装。完成这些步骤之后，就可以开始创建 Buildbot 了！如果安装过程进行得很顺利，在 shell 提示符处输入：
$ paster create -t buildbot my.project
$ cd my.project
现在设置已经快完成了，但在完成之前，我要提几个在首次配置 Buildbot 时您容易出错的地方。在您的 my.project/master.cfg 文件中，应该可以看到以下内容：
清单 1. master.cfg 内容
[buildout]
master-parts =
master
passing.project
# uncomment this to enable polling
poller
[master]
recipe = collective.buildbot:master
project-name = passing.project project
# allow to force build with the web interface
allow-force = true
# internal port
port = 9051
# http port
wport = 9081
# buildbot url. change this if you use a virtualhost
url = http://localhost:9081/
# static files
public-html = ${buildout:directory}/public_html
slaves =
localhost NaOaPSWb
[passing.project]
recipe = collective.buildbot:project
slave-names = localhost
vcs = hg
repositories = /home/ngift/myhgrepo
# notifications
mail-host = localhost
email-notification-sender = buildbot@cortese
email-notification-recipient =
[email protected]
# run test each hour
periodic-scheduler=60
# cron build
cron-scheduler = 0 8 * * *
# You can change the sequences to build / test your app
# default options should work for most buildout based projects
build-sequence =
# /usr/bin/python2.5 bootstrap.py -c project.cfg
# /usr/bin/python2.5 bin/buildout -c project.cfg
test-sequence =
nosetests
# zope.testing require exit with status
# bin/test --exit-with-status
[poller]
recipe = collective.buildbot:poller
# don't forget to check this
# since it's generated from the paster template it may be a wrong url
repositories = /home/ngift/myhgrepo
#user = h4x0r
#password = passwd
poll-interval = 120
最初检查最重要的内容是确保有合适的源控制存储库，一开始将 build-sequence 留空，当代码迁出您为它提供的存储库时，您的 test-sequence（在我的例子中是 “nose”）会通过测试。如果您有其他问题，请查阅 collective.buildbot 资源指南。
设置好配置文件之后，只需运行下面两个命令：
$ python bootstrap.py
$ ./bin/buildout
在运行 buildout 命令时，您会看到以下输出：
清单 2. buildout 命令的输出
{673} > ./bin/buildout
Unused options for buildout: 'master-parts'.
Installing master.
New python executable in /home/ngift/my.project
Installing setuptools............done.
[output suppressed for space]
该命令结束之后，您就完成了 Buildbot 的安装，现在就可以使用它了。运行以下 shell 命令启动 Buildbot 守护进程：
$ ./bin/master start $ ./bin/yourhostname start
如果您在浏览器中输入在主 .cfg 文件中设置的 URL，默认情况下为 http://localhost:9081/，您会看到全新的 Buildbot。当然，它现在可能还没有多少功能。如果您为它提供一个构建脚本和一个测试运行程序，它会很乐意检查、构建并自动测试您的代码。当然，您稍后应当浏览一些配置选项，但最难的部分已经完成了。
生成代码度量报告
“测试迷” 中一个最新的智能开发，是要利用持续集成周期来生成有关源代码的度量。其中一种最流行的方法是运行带既定选项的 nosetest 测试收集器。如果您有一个名为 “foo” 的项目，您通常会运行：
nosetests --with-coverage --cover-package=example --cover-html \
--cover-html-dir=example_report.html test_example.py
这会生成一个 HTML 报告，显示未涉及的所有代码行，以及类似于清单 3 的 stdout 的输出：
清单 3. nosetest 输出
nglep% nosetests --with-coverage --cover-package=example
--cover-html-dir=example_report.html test_example.py
.
Name Stmts Exec Cover Missing
---------------------------------------
example 2 2 100%
----------------------------------------------------------------------
Ran 1 test in 0.004s
OK
您可以从 下载 部分下载 example.py 和 test_example.py。
每次修改代码后都运行这个报告，为开发人员和管理人员提供有关代码变化的元数据。这是展示为何同时运行度量标准的一个绝佳例子，因为 CI 对一个项目有好处。
另一个提供代码元数据的度量工具是 PyMetrics 的 McCabe 评定。早在20 世纪 70 年代，Thomas McCabe 就提出一个简单、但独创性的代码观察结论：一段代码越复杂，它中断的可能性就越大。这虽然看起来很明显，但遗憾的是，很多开发人员似乎看不到其中的联系。使用 PyMetrics 的命令行工具，您可以确定每个函数的分支数。
通常，您希望将编写的每个方法或函数的分支数保持在 10 以下，因为在人脑中保留 7 或 8 份内容很难。类似的，大于 50 段的代码基本上是无法测试/无法维护的。
I have personally seen more than 140 sections of the code, the code is very poor, it does demonstrate the McCabe's theory. If you can capture and mark early in the development of this complex, fragile code, even if all tests are passed, it will not appear in a production environment.
Conclusion
The main advantage of continuous integration is the ability to build and testing and software metrics (optional) to streamline the quality assurance cycle by automating the software. Each time you change the source code and provide immediate feedback and reporting time will trigger construction of the project life cycle. CI When properly configured, it is actually integrated into the code generation process, the same as personally involved in writing code.
Buildbot CI is not the only tool for testing. You can also look at Hudson and Bitten. They support the use of Python plug-in customization, even if Hudson is written in Python. See the following references to learn more about these system-related content.
Reproduced in: https: //www.cnblogs.com/licheng/archive/2010/12/04/1896278.html