Python 代碼庫的持續集成系統

Question

我開始使用Python代碼庫開展一個業余愛好項目，我想建立某種形式的持續集成（即每次簽到時運行一組測試用例並向負責人發送煩人的電子郵件測試失敗時的人員）類似於CruiseControl或TeamCity 。

我意識到我可以在大多數VCS 中使用鈎子來做到這一點，但這要求測試與版本控制服務器在同一台機器上運行，這並不像我想要的那么優雅。 有沒有人對適合Python代碼庫的小型、用戶友好、開源持續集成系統有任何建議？

Answer 1

我們在工作中運行Buildbot - Trac 。 我沒有過多使用它，因為我的代碼庫還不是發布周期的一部分。 但是我們在不同的環境（OSX/Linux/Win）上運行測試，它會發送電子郵件——它是用 Python 編寫的。

Answer 2

一種可能性是哈德遜。 它是用 Java 編寫的，但與 Python 項目集成：

哈德森擁抱 Python

然而，我自己從未嘗試過。

（更新，2011 年 9 月：在商標糾紛之后，Hudson 更名為Jenkins 。）

Answer 3

其次是 Buildbot - Trac 集成。 您可以在Buildbot 網站上找到有關集成的更多信息。 在我之前的工作中，我們編寫並使用了他們提到的插件 (tracbb)。 該插件的作用是重寫所有 Buildbot url，以便您可以在 Trac 中使用 Buildbot。 （ http://example.com/tracbb ）。

Buildbot 真正的好處是配置是用 Python 編寫的。 您可以將自己的 Python 代碼直接集成到配置中。 編寫自己的 BuildSteps 來執行特定任務也很容易。

我們使用 BuildSteps 從 SVN 獲取源代碼、拉取依賴項、將測試結果發布到 WebDAV 等。

我編寫了一個 X10 接口，以便我們可以發送帶有構建結果的信號。 當構建失敗時，我們打開了一盞紅色的熔岩燈。 構建成功后，綠色熔岩燈亮起。 美好時光 ：-）

Answer 4

我們同時使用 Buildbot 和 Hudson 進行 Jython 開發。 兩者都是有用的，但有不同的優點和缺點。

Buildbot 的配置是純 Python 的，一旦你掌握了它就非常簡單（查看 epydoc 生成的 API 文檔以獲取最新信息）。 Buildbot 使定義非測試任務和分發測試人員變得更加容易。 然而，它確實沒有單獨測試的概念，只有文本、HTML 和摘要輸出，因此如果您想要多級可瀏覽的測試輸出等等，您必須自己構建它，或者只使用 Hudson。

Hudson 非常支持從整體結果深入到測試套件和單個測試； 它也非常適合比較構建之間的測試輸出，但分布式（主/從）的東西相對更復雜，因為你也需要在從屬上有一個 Java 環境； 此外，Hudson 對 master 和 slave 之間不穩定的網絡鏈接的容忍度較低。

因此，為了獲得這兩種工具的優勢，我們運行 Hudson 的單個實例，它會捕獲常見的測試失敗，然后我們使用 Buildbot 進行多平台回歸。

以下是我們的實例：

• 傑通·哈德森
• Jython 構建機器人

Answer 5

我們正在使用與 trac 集成的Bitten 。 它是基於python的。

Answer 6

TeamCity 有一些 Python 集成。

但 TeamCity 是：

• 不是開源的
• 不是小，而是功能豐富
• 中小團隊免費。

Answer 7

對於較小的代碼庫，我在Travis-CI方面有很好的經驗。 主要優點是：

• 設置在不到半屏的配置文件中完成
• 您可以自行安裝或僅使用免費托管版本
• github 存儲庫的半自動設置
• 網站上不需要帳戶； 通過github登錄

一些限制：

• Python 不被支持作為第一類語言（截至撰寫本文時；但您可以使用 pip 和 apt-get 來安裝 Python 依賴項；請參閱本教程）

• 代碼必須托管在 github 上（至少在使用官方版本時）