使用 Buildot 实现持续集成

核心提示： 这会生成一个 HTML 报告，显示未涉及的所有代码行，使用 Buildot 实现持续集成(6)，以及类似于清单 3 的 stdout 的输出：清单 3. nosetest 输出nglep%nosetests--with-coverage--cover-package=example--cover

这会生成一个 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 段的代码基本上是无法测试/无法维护的。

我就亲眼看到过 140 多段的代码，代码很差，它确实验证了 McCabe 的理论。如果您可以在开发前期捕获和标记这个复杂、脆弱的代码，那么即使所有测试都通过，它也不会出现在生产环境中。

结束语

持续集成的主要优势是，能够通过软件的自动化构建以及测试和软件度量标准（可选）精简品质保证周期。每次更改源代码并为项目生命期提供即时反馈和报告时，都会触发构建。当 CI 得到正确配置时，它实际上就集成到代码生成过程中，如同亲自参与编写代码一样。

Buildbot 并非用于 CI 测试的惟一工具。您也可以了解一下 Hudson 和 Bitten。它们都支持使用 Python 插件进行定制，即使 Hudson 是用 Python 编写的。参阅以下的参考资料，详细了解这些系统相关内容。

本文示例源代码或素材下载