コミットする前にマルチプラットフォームのビルド/テストを自動化または促進する方法は？

Question

当社のソフトウェアは、LinuxおよびWindowsプラットフォームで構築されています。開発者の好みに応じて、いずれかのプラットフォームでコントリビューションが開発およびテストされ、Subversionリポジトリにコミットされます。その後、その貢献は他のプラットフォーム上で構築されないことがわかり、修正が必要です。他のプラットフォームでの修正により、元のプラットフォームでのビルドが再び壊れる可能性があります。

コミットする前に、他のプラットフォームでもコントリビューションが構築される（そして回帰テストされる）ことを望みます。継続的なビルドサーバー（CruiseControl）がありますが、そのサーバーはリポジトリからビルドされます。継続的なビルドサーバーが、コミット前のチェックとして他のプラットフォーム上でビルドし、ビルドとテストが成功した場合にそれらをコミットするソリューションを探しています。

提案はありますか？

Answer 1

Matheiu Godlewskiは CruiseControl wiki

彼の提案を veto 要素と組み合わせると、設定する必要があります。

Answer 2

Teamcityは事前にテストされたコミットを処理します。4.0の新しいビルドチェーン機能を使用して何かを実行できる場合があります（ http://www.jetbrains.com/teamcity/features/newfeatures.html ）。エージェントはクロスプラットフォームであり、ビルドの特定のビットのみを実行するように構成できるため、テストのサブセットのみを実行するように構成できます。

実際にはこれを行っていないことに注意してください：）

Answer 3

2つのブランチを作成する方が簡単な場合があります。1つはユーザーがチェックインするブランチで、もう1つは継続的な統合に合格した後に変更をマージするブランチです。

Answer 4

複数のOS（および複数のOS上の複数のデータベース製品）にリモートで展開できるカスタムビルドおよびテストリグを使用しました。これは、翌朝にバグを修正するというルールを備えた夜間ビルドとして行われました。

その場合、完全に連続することはできませんが、事前コミットフックで行うには多くの作業が必要になる可能性があります。特に、ソース管理リポジトリが事前コミットフックの実行中に影響を受けるファイルをロックする場合。

日中、コミットごとに実行する継続的統合テストと、夜間に実行するシステム統合テストには違いがあると思います。

Answer 5

Douglas Leederは、「統合」を提案しました。ブランチ-それの良いところは、自動化できることです。テストに合格した場合-「トランク」にマージします。

一部のバージョン管理システム（bzr / hg / gitなど）は、他のバージョン管理システムよりも簡単ですが、ほとんどの場合は可能です。