3

私はビルド プロセスと継続的インテグレーションの自動化にかなり慣れていないため、小さな開発者チームのためにビルド プロセス/サーバーのセットアップに取り組んでいます。SVN、CMake、および Jenkins ビルド サーバーを使用しています。ソース言語は C++ です。

library(dll) と の2 つのプロジェクトがあるとしexecutableます。executableへのリンクがlibraryあるため、ビルドexecutableするには .lib および .h ファイルが必要ですlibrary。を実行するexecutableには、.dll (および場合によってはデバッグ シンボル ファイル) が必要ですlibrary

全体をビルドするときは、かなり単純で、リポジトリから最新のソースを取得してビルドしlibraryますexecutable

ただし、複数の開発者がおり、各開発者は通常、一度に 1 つのプロジェクトに取り組んでいます。私たちの CMake スクリプトを使用すると、ビルドするプロジェクトを選択できるため、 builds のみのセットアップと、buildsJohnのみのセットアップがある場合があります。これをあきらめるという選択肢はありません。executableBoblibrary

したがって、ソースにBob変更を加えてlibraryコミットする場合はJohn、コンパイル済みの .lib および .dll ファイルを取得する必要があります (彼はコンパイルしていないためlibrary)。

現在、バイナリは svn にあります。各コンパイル中に、CMake はコンパイル前のステップとして にコピーsrc/binbuild/bin、次に、選択されたプロジェクトがコンパイルされ ( の適切なバイナリを置き換えますbuild/bin)、最後に CMake が にコピーbuild/binsrc/binます。

これはBob、変更を行うときに、ソース ファイルだけでなくコンパイル済みのバイナリもコミットしJohn、作業コピーを更新すると適切なバイナリを取得し、手動でファイルを置き換える必要がないことを意味します。

これはしばらくの間機能していましたが、いくつかの理由で本当に好きではありません。このようなものを設定するハックっぽい方法はありませんか? (実際には 4 人の開発者がいて、約 12 のプロジェクトがあり、何にも依存しないライブラリ、他のライブラリに依存するライブラリ、他のライブラリに依存する実行可能ファイルなどがあります。)

編集:これは私が考えているプロセスです:

Artifactory や Nexus などのアーティファクト追跡システムを使用して、ビルド後にバイナリを保存し、それらのバイナリの生成に使用されるヘッダー ファイルを保存します。

CMake では、各プロジェクトはコンパイル済みまたはプリコンパイル済みとしてマークされます。コンパイルされたプロジェクトは、通常のリポジトリから生成されます。プリコンパイルされたプロジェクトのバイナリとヘッダーが古い場合は Nexus からダウンロードされ、CMake のリンクとインクルードが適切に行われます。Dave Bacher の回答へのコメントで説明した競合状態を防ぐために、ヘッダーもアーティファクトと共に保持されます。

私が気に入らない唯一のことは、アーティファクトが古くなっているかどうかを確認してダウンロードするためにCMake-fooを実行する必要があることですが、どうやら私が試していることから、実際には代替手段はないと思います設定するのは非常に非標準です。

4

2 に答える 2

2

開発者のビルドを、他の開発者がビルドする標準参照としてチェックインするのは好きではありません。それは脆弱であり、その環境で 1 人の人には機能するが、他の人には失敗する悪いビルドになってしまう可能性があります。または、誰かが変更を加えたものの、ファイルをチェックインするのを忘れてしまい、突然、プロジェクトの一部をビルドできるのはその人だけになった場合です。

少なくとも、ライブラリと実行可能ファイルをビルドする場所として Jenkins をセットアップし、開発者にソースのみをチェックインさせる必要があります。Jenkins には、標準のビルド環境でビルドした後にライブラリと実行可能ファイルを公開するために使用できるプラグイン ( SVN Publisherなど) がいくつかあります。

私の経験では、Jenkins をビルド マシンにインストールし、プロジェクトごとにビルドをセットアップするのは非常に簡単です。これで、各プロジェクトのビルドを検証する最初のステップを開始できます。次に、開発者にビルドの発行を依頼するのではなく、Jenkins にその出力を発行させる作業を行います。

于 2012-04-30T17:24:10.807 に答える
1

現在導入されているシステムでは、実行可能ファイルとライブラリの変更者の間で競合状態が常に発生するようです。すべての開発者の競合状態を解決する方法に集中しようとするのではなく、CI を使用して競合状態から発生する可能性のある問題をキャッチすることをお勧めします。

あなたは始めたばかりなので、私はシンプルに保ち、何かがリポジトリにチェックインされるたびに全体を構築する Jenkins ジョブの作成に集中します。ライブラリと実行可能ファイルが同じ SVN リポジトリに保持されていると仮定すると、ジョブのアクションは次のようになります。

  1. リポジトリをチェックアウト
  2. CMake を実行してライブラリをビルドする
  3. ライブラリの単体テストを行います (いくつかありますよね?)
  4. CMake を実行して、ライブラリに対して実行可能ファイルをビルドします
  5. 実行可能ファイルの単体テストを行います (いくつかありますよね?)
  6. ビルドの結果を開発者に通知します。

些細なことのように思えますが、これにより開発者は、コピーを更新することを忘れないように強制することなく、変更によって物事が壊れているかのようにフィードバックを得ることができます。また、CI を使った作業のパラダイム シフトを容易にするのにも役立ちます。

[ところで、開発者が遭遇する可能性のある落とし穴の 1 つは、一度にファイルを SVN にチェックインすることに慣れている場合です。ファイルごとの変更を行うと、最後のファイルが最終的にチェックインされたときにのみ成功する複数のビルドが開始されます。複数のファイルのチェックインは、一度に複数のファイルでアトミック アクションとして実行する必要があります。これは、追跡および (必要に応じて) ロールバックできる 1 つのものに変更をグループ化するため、SCM の優れたプラクティスでもあります。]

パラダイム シフトは、最初は乗り越えられないように思えるかもしれませんが、実際に起こる可能性があります。私が現在取り組んでいるプロジェクトは、上で説明したのと非常によく似たプロセスに慣れている開発者から始まりました。CI の実行に移行したとき、週に 1 回よりも頻繁にコードをチェックインすることに抵抗がありました。8 か月後、Jenkins ビルドのメンテナンスを行う必要がある場合、すぐに Jenkins が利用できない理由と、「ビルド結果をすぐに返せない場合、人々はどのように機能することを期待できるでしょうか?」という質問が殺到します。 "

于 2012-04-30T19:15:40.817 に答える