Python代码库的持续集成系统
我开始使用Python代码库进行一个业余项目，并且希望建立某种形式的持续集成(即，每次签入时都要运行一堆测试用例，并向负责人发送垃圾邮件测试失败的人员)类似于CruiseControl或者TeamCity。
我意识到我可以在大多数VCS中使用钩子来做到这一点，但是这要求测试必须与版本控制服务器在同一台计算机上运行，这并不是我想要的那么优雅。对于适合于Python代码库的小型，用户友好型，开源持续集成系统，是否有人有任何建议？
解决方案：
哈德森就是一种可能性。它是用Java编写的，但是与Python项目集成在一起：
Hudson embraces Python
但是，我自己从未尝试过。
(2011年9月更新：在商标争议之后，Hudson已重命名为Jenkins。)
我们在工作中运行Buildbot Trac。因为我的代码库还不是发布周期的一部分，所以我并没有使用太多。但是我们在不同的环境(OSX / Linux / Win)上运行测试，并且它发送电子邮件并使用Python编写。
其次是Buildbot Trac集成。我们可以在Buildbot网站上找到有关集成的更多信息。在上一份工作中，我们编写并使用了他们提到的插件(tracbb)。
插件的作用是重写所有Buildbot网址，以便我们可以在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实例，该实例捕获了常见的测试失败，然后使用Buildbot进行了多平台回归。
这是我们的实例：
Jython Hudson Jython buildbot不是开源的也不小，但是功能丰富的软件对于中小型团队是免费的。
我们正在使用与Trac集成的Bitten wich。它是基于python的。
TeamCity具有一些Python集成。
但是TeamCity是：
{分块}
