5

私は、開発プロセスを（ゆっくりと）より近代的なものにアップグレードしている組織で大規模なプロジェクトに取り組んでいます。現在、継続的インテグレーション モデルへの移行を検討しています。この動きの一環として、独自の継続的インテグレーション サーバーを作成することを検討しています。非常に成熟した (やや骨化した) ビルド プロセスがあります。また、ビルド検証テストとして実行したい多数のテストがあります。

私たちはいくつかの商用 CI サーバーを調査しましたが、個々のニーズに合わせてそれらをカスタマイズするのに必要な作業量は比較的多いようです。非常に高いため、独自の CI サーバーをカスタム作成するだけの価値があるかもしれません。ただし、このプロセスの潜在的な落とし穴を見逃している可能性があると感じています。実装におけるバグの問題が提起され、検討されています。オプションを評価する際に留意すべきその他の主要な考慮事項 (もちろん、CI システムの作成にかかる労力以外) はありますか? カスタム CI サーバーを実装したことがある人から、具体的な問題は何でしたか? また、商用 CI システムを使用したことのある人から、自分でやっておけばよかったと思うことや、やらなくてよかったと思うことはありますか?

4

6 に答える 6

14

この NIH の考え方に反対することを強くお勧めします。

  • CruiseControl.NET などのオープン ソース CI サーバーの変更を検討する
  • カスタム Nant タスクの作成を検討する
  • プロジェクトを既存のオプションにより適したものに変更することを検討してください
  • 継続的インテグレーションのビジネスに関わりたくない、単にそれを使用してメリットを確認したい
于 2009-05-20T17:26:01.673 に答える
9

本格的な CI サーバーの代わりに、必要なカスタマイズされた部分を構築してみませんか? すべてをカスタムするのではなく、できる限り再利用してください。少なくともいくつかの部品を既製にすることができます。

（ちなみに、これを「NIH」とは呼びません）

既存の CI サーバーで動作するようにビルドを構成するのに、独自のサーバーをビルドするのと同じくらいの時間を費やしたとしても (おそらくここでは寛大です)、フレームワーク全体ではなく、各カスタム ビットのみを維持する必要があることに注意してください。

活用できるものを確認し、それを使用して作業してください。また、どのツールがあなたの目指す方向に進む可能性があるかを確認してください。箱から出してすぐにあなたの環境で完璧に動作する CI サーバーはありません。それらはすべて微調整して「途中で満たす」必要があります。

于 2009-05-20T17:22:10.417 に答える
3

これをうまく行うことは、決して小さな努力ではありません-オープンソースコミュニティは、少なくとも第3世代のオープンソースCIサーバー上にあります-その過程で多くの教訓を学びました。

簡単に拡張できる既成のCIサーバーの1つを見て、不足している部分を構築することをお勧めします。あなたの質問には、既存のCIサーバーのほとんどで行われていない（そして非常にうまく行われている）ものは何もありません。

オープンソースソリューションに移行する前に、「貧乏人」の内部CIシステムを実装しましたが、オープンソースシステムは非常に優れており、完全で、堅牢であるため、私の努力は無意味でした。

特に、拡張性を探している場合は、Hudsonが最適です。プラグインアーキテクチャが優れており、作成者は有料のコンサルティング作業を利用できます。おそらく、リソースを自分で作成するよりもはるかに有効に活用できます。

余談ですが、ビルドプロセスに関与する前は、製品のビルドは14.5時間で、自動テスト、パッケージ化、CMはありませんでした。いくつかの努力のおかげで、既存のCIコミュニティによって提示されたベストプラクティスに従って、同じプロジェクトビルドは、自動テスト、パッケージ化、およびCMを使用して7.5分に短縮されます。私の経験では、CIを既存のビルドに曲げようとするのではなく、経験豊富なCIコミュニティの既存のベストプラクティスに準拠するようにビルドを操作することは間違いなく価値があります。

于 2009-05-20T17:42:56.523 に答える
1

私が考えること：

  • このドメインのチームではどのような経験がありますか？
  • チームのメンバーがCIサーバーの設計について学ぶために時間をかけることができるようなタイムラインですか？
  • チームを補完するために、このドメイン知識を持つ人々を雇う予算はありますか？
  • なぜこれを既存のソリューションよりもうまくできると思いますか？
于 2009-05-20T17:41:52.750 に答える
1

私もこの道を歩んできました。私はこれまでに働いてきたさまざまな企業のために、社内の自動ビルドシステムを 3 回作成しました。いつも楽しくて、私は筆記具が好きなタイプです。

しかし、結局のところ、それは決してプロフェッショナルなシステムではありませんでした。それは常に十分に機能し、私たちのために機能し、私たちをうまくやってのけるシステムでした. もちろん、休暇に行ったり、別の都市で会議に出席したりした場合を除きます。町を出るたびに、ビルドが失敗し、失敗し、失敗するようになりました。私たちのコードの問題ではなく、ビルド システムで日常的に処理する些細なことが原因でした。そして、私がそれらを処理するためにそこにいなかったとき、他の誰も何をすべきかを知りませんでした.

これらすべてが、私たちの主な焦点である独自のソフトウェア開発から時間を奪いました。

最後に、(私の勧めで) 私が書いた手作りの perl スクリプト システムを捨て、商用システムを購入しました: Zed Builds and Bugs

さて、何か問題が発生した場合、それは私たち自身のコードの問題です。ベンダーのビルド システムが機能します。質問がある場合は、質問するか、ユーザーのコミュニティに質問します。何かを行う方法を理解する必要がある場合、質問に答えてくれる人がいます。

そして最も重要なことは、再び休暇を取ることができることです :-)

私は今でもビルド システムのほとんどのタスクを処理していますが、それを書くことはもはや問題ではありません。これは、既存のメイクファイル、Visual Studio プロジェクト、Ant ビルド スクリプトなどを新しいシステムに適応させる問題です。

私を信じてください、この場合、購入するよりも構築する方がはるかに簡単です. あなたのコア ビジネスは、ビルド システムを作成することではありません (または、質問をしたことはないでしょう)。コア ビジネスに集中し、その他すべてに必要なツールを購入します。

于 2009-05-22T01:44:46.963 に答える
0

私の観点からいくつかのヒントを与えようとするかもしれません。当社では、ビルド環境とターゲット環境の異なる構成を使用していました。異なる構成とは、異なるシステムアーキテクチャを意味します。そして、これが私が説明したい点です。（これがあなたの実際の問題であるかどうかはわかりませんが）。

製品のビルドはビルド環境で行われ、テストと製品自体を実行するには、ターゲット環境に転送する必要があります。したがって、クロスコンパイルが必要でした。商用またはオープンソースの継続的インテグレーションソリューションは使用しませんでしたが、一連のbashスクリプトを使用しました（妥当なソリューションを作成する時間がありませんでした:(）テストの実行（ユニット、統合、健全性、コンポーネントなど）は、ターゲットで実行する必要があります。

それで、あなたが尋ねるかもしれない質問は-開発環境とは何ですか？テストはどこで実行しますか？（ターゲットでテストを実行しており、ビルド環境でもテストの一部を実行しています）ターゲット環境は開発環境と同じですか？さまざまな構成（プラットフォーム、ソフトウェアなど）用にビルドする必要がありますか？

使用している言語を指定していません。私はそれが無関係かもしれないことを知っていますが、そうではありません:)（Javaでさえ異なるプラットフォーム（x86とx86-64）で異なった振る舞いをします）

テストによるコードのカバレッジ、ドキュメントタスクの実行前（前..）に実行される静的コード分析など、このタスクは個別のプラグインとして実行できるため、あまり面白くないと思います。

于 2009-05-20T17:41:09.490 に答える