我开始使用 Python 代码库从事一个爱好项目，我想建立某种形式的持续集成（即每次签入时运行一系列测试用例类似CruiseControl或TeamCity。
我意识到我可以在大多数 VCS 中使用钩子来做到这一点，但这需要测试与版本控制服务器在同一台机器上运行，这并不像我想要的那样优雅。有人对适合 Python 代码库的小型、用户友好、开源持续集成系统有什么建议吗？
【问题讨论】：
标签： python continuous-integration extreme-programming
【讨论】：
nosetests --with-xunit --with-coverage，带有“Violations”插件的 pylint，以及用于覆盖的“Cobertura”
我们在工作中运行Buildbot - Trac。我没有过多地使用它，因为我的代码库还不是发布周期的一部分。但是我们在不同的环境（OSX/Linux/Win）上运行测试，它会发送电子邮件——而且它是用 Python 编写的。
【讨论】：
第二个 Buildbot - Trac 集成。您可以在Buildbot website 上找到有关集成的更多信息。在我之前的工作中，我们编写并使用了他们提到的插件 (tracbb)。 该插件所做的是重写所有 Buildbot url，以便您可以在 Trac 中使用 Buildbot。 (http://example.com/tracbb)。
Buildbot 真正的好处是配置是用 Python 编写的。您可以将自己的 Python 代码直接集成到配置中。编写自己的 BuildSteps 来执行特定任务也非常容易。
我们使用 BuildSteps 从 SVN 获取源、拉取依赖项、将测试结果发布到 WebDAV 等等。
我编写了一个 X10 接口，以便我们可以发送带有构建结果的信号。当构建失败时，我们打开了一盏红色熔岩灯。构建成功后，绿色的熔岩灯亮了。美好时光:-)
【讨论】：
我们同时使用 Buildbot 和 Hudson 进行 Jython 开发。两者都很有用，但有不同的优点和缺点。
Buildbot 的配置是纯 Python 的，一旦掌握了它就非常简单（查看 epydoc 生成的 API 文档以获取最新信息）。 Buildbot 可以更轻松地定义非测试任务和分配测试人员。但是，它确实没有单独测试的概念，只有文本、HTML 和摘要输出，所以如果你想拥有多级可浏览的测试输出等，你必须自己构建它，或者只使用 Hudson。
Hudson 为从整体结果向下钻取到测试套件和单个测试提供了极好的支持；它也非常适合比较构建之间的测试输出，但是分布式（主/从）的东西相对更复杂，因为您也需要在从属上的 Java 环境；此外，Hudson 对主从之间的不稳定网络链接的容忍度较低。
因此，为了获得这两种工具的优势，我们运行一个 Hudson 实例，它会捕获常见的测试失败，然后我们使用 Buildbot 进行多平台回归。
这是我们的实例：
【讨论】：
我们正在使用Bitten，它与 trac 集成。它是基于 python 的。
【讨论】：
【讨论】：
对于较小的代码库，我对 Travis-CI 有很好的体验。 主要优点是：
一些限制：
不支持 Python 作为第一类语言（截至撰写本文时；但您可以使用 pip 和 apt-get 安装 python 依赖项；请参阅this tutorial）
代码必须托管在github上（至少在使用正式版时）
【讨论】：