私はPythonコードベースを使用した趣味のプロジェクトに取り組み始めており、何らかの形の継続的インテグレーションをセットアップしたいと考えています (つまり、チェックインが行われるたびに一連のテスト ケースを実行し、担当者にナグ メールを送信します)。テストが失敗したときの人) CruiseControlまたはTeamCityに似ています。
ほとんどのVCSesでフックを使用してこれを実行できることはわかっていますが、それにはバージョン管理サーバーと同じマシンでテストを実行する必要があり、これは私が望むほどエレガントではありません。Pythonコードベースに適した、小さくて使いやすいオープンソースの継続的インテグレーション システムについて何か提案はありますか?
仕事でBuildbot - Tracを実行しています。私のコードベースはまだリリース サイクルに含まれていないため、あまり使用していません。しかし、さまざまな環境 (OSX/Linux/Win) でテストを実行すると、電子メールが送信されます。これは Python で記述されています。
1つの可能性はハドソンです。Java で書かれていますが、Python プロジェクトとの統合があります。
ただし、自分で試したことはありません。
(更新、2011 年 9 月: 商標紛争の後、Hudson はJenkinsに改名されました。)
2番目のBuildbot-Trac統合。統合の詳細については、BuildbotのWebサイトを参照してください。私の前の仕事では、彼らが言及しているプラグイン（tracbb）を作成して使用しました。プラグインが行うことは、Trac内からBuildbotを使用できるように、すべてのBuildbotURLを書き換えることです。（http://example.com/tracbb）。
Buildbotの本当に素晴らしい点は、構成がPythonで記述されていることです。独自のPythonコードを構成に直接統合できます。特定のタスクを実行するための独自のBuildStepを作成することも非常に簡単です。
BuildStepsを使用して、SVNからソースを取得し、依存関係をプルし、テスト結果をWebDAVに公開しました。
ビルド結果を含むシグナルを送信できるように、X10インターフェイスを作成しました。ビルドが失敗したとき、私たちは赤い溶岩ランプをオンにしました。ビルドが成功すると、緑色の溶岩ランプが点灯しました。良い時:-)
Jython 開発には Buildbot と Hudson の両方を使用しています。どちらも便利ですが、長所と短所が異なります。
Buildbot の構成は純粋な Python であり、慣れれば非常に単純です (最新情報については、epydoc で生成された API ドキュメントを参照してください)。Buildbot を使用すると、テスト以外のタスクの定義とテスターの配布が容易になります。ただし、実際には個々のテストの概念はなく、テキスト、HTML、および要約出力のみであるため、マルチレベルのブラウズ可能なテスト出力などが必要な場合は、自分で作成するか、Hudson を使用する必要があります。
Hudson は、全体的な結果からテスト スイートおよび個々のテストにドリルダウンするための優れたサポートを提供しています。ビルド間でテスト出力を比較するのにも最適ですが、スレーブにも Java 環境が必要なため、分散 (マスター/スレーブ) のものは比較的複雑です。また、ハドソンは、マスターとスレーブ間の不安定なネットワーク リンクに対する耐性が低くなります。
したがって、両方のツールの利点を得るために、Hudson の単一のインスタンスを実行し、一般的なテストの失敗をキャッチしてから、Buildbot を使用してマルチプラットフォームの回帰を行います。
ここに私たちの例があります：
私たちは、tracと統合されたBittenを使用しています。そしてそれはPythonベースです。
TeamCity にはいくつかの Python統合があります。
しかし、TeamCity は次のとおりです。
小規模なコード ベース向けのTravis-CIについては、非常に良い経験があります。主な利点は次のとおりです。
いくつかの制限:
Python は第一級言語としてサポートされていません (執筆時点では; ただし、pip と apt-get を使用して Python の依存関係をインストールできます;このチュートリアルを参照してください) 。
コードは github でホストする必要があります (少なくとも公式バージョンを使用する場合)