当社のソフトウェアは、Linux および Windows プラットフォーム上に構築されています。開発者の好みに応じて、コントリビューションはいずれかのプラットフォームで開発およびテストされ、サブバージョン リポジトリにコミットされます。その後、コントリビューションが他のプラットフォームではビルドされないことが判明し、修正が必要になります。他のプラットフォームでの修正により、元のプラットフォームでのビルドが再び壊れる可能性があります。
コントリビューションがコミットされる前に、他のプラットフォームでもビルド (およびリグレッション テスト) されることを確認したいと思います。継続的なビルド サーバー (CruiseControl) がありますが、そのサーバーはリポジトリからビルドされます。継続的なビルド サーバーがプリコミット チェックとして他のプラットフォームでビルドし、ビルドとテストが成功した場合にコミットするソリューションを探しています。
助言がありますか？
Teamcity は事前テスト済みのコミットを処理します。4.0 の新しいビルド チェーン機能 ( http://www.jetbrains.com/teamcity/features/newfeatures.html ) を使用して何かを実行できる場合があります。エージェントはクロスプラットフォームであり、ビルドの特定のビットのみを実行するように構成できるため、テストのサブセットのみを実行するように構成できます。
私は実際にこれを行っていないことに注意してください:)
1 つは人々がチェックインする場所で、もう 1 つは継続的インテグレーションを通過した後に変更をマージする場所です。
MatheiuGodlewskiがCruiseControlwikiで良い提案をしました
彼の提案と拒否権の要素を組み合わせると、設定する必要があると思います。
複数の OS (および複数の OS 上の複数のデータベース製品) にリモートでデプロイできるカスタム ビルドおよびテスト リグを使用しました。これは、翌朝にバグを修正するというルールで夜間ビルドとして行われました。
その場合、完全に継続的ではありませんが、プレコミットフックで行うには多くの作業が必要になる可能性があります。特に、ソース管理リポジトリが pre-commit フックの実行中に影響を受けるファイルをロックしている場合。
コミットごとに日中実行される継続的インテグレーション テストと、夜間に実行されるシステム インテグレーション テストには違いがあると思います。
Douglas Leeder さんは「統合」ブランチを提案しました。これの良いところは、自動化が可能なことです。テストに合格したら、「トランク」にマージします。
一部のバージョン管理システム (bzr/hg/git など) は他のシステムよりも簡単ですが、ほとんどのシステムで可能です。