ソースコードまたはバイナリに依存するには?


9

BがAに依存する異なるチームによって開発された2つの社内プロジェクトAとBがあります。両方のプロジェクトのソースコードはgitに格納されているため、プロジェクトAをサブモジュールとしてプロジェクトBに含め、ビルドシステムを構成しました両方を正しい順序で構築します。別の解決策は、ArtifactoryやNexusなどのバイナリリポジトリマネージャーを介してAを使用することです。

ソースコードに依存するか、バイナリアーティファクトに依存するかの長所と短所について疑問に思います。どちらが他より優れているのですか?これまでのところ、次のような要素を考え出すことができましたが、他の意見を聞くのはとても楽しみです。

ソースコードに応じてより良いです

  • バイナリレポジトリマネージャーがない場合
  • 別のプロジェクトのプレリリースバージョンに依存する必要がある場合
  • 別のプロジェクトにパッチを適用する必要がある場合
  • IDEで依存関係のソースコードを簡単に参照できるため

バイナリに依存する方が良い

  • ビルド時間を最小限にする
  • 別のプロジェクトのビルド環境をセットアップする手間を避けるため

1
私の経験では、別のプロジェクトにパッチを適用できる可能性が重要です。パッチがマスターに戻されないこともあります(プロジェクト固有の拡張/変更)。このような場合は、とにかく依存プロジェクトのビルド環境をセットアップする必要があります。したがって、ソースコードの依存関係を使用します。しかし、もちろん、それはあなたのプロセス/アーキテクチャに依存します。
proskor 2014

回答:


5

ソースの依存関係よりもバイナリの依存関係を常にお勧めします。ソースコードとしてリストしたプロのほとんどは、バイナリの依存関係にも簡単に組み込むことができます。

まず、一部のローカルサーバーにNexusリポジトリを設定するのはとても簡単です。バイナリレポを使用する利点は、セットアップの労力/コストをはるかに上回ります。これは私の答えの残りの部分のほとんど前提条件です:)

プレリリースバージョンの場合、プロジェクトは-SNAPSHOTバージョンをアーティファクトにデプロイする必要があります。次のように、バージョン間に明確で明確な違いがある場合があります。

  • projectA-3.2.0-SNAPSHOT :アクティブな開発、いつでも変更される可能性があります
  • projectA-3.2.0-RC1 : リリース候補版
  • projectA-3.2.0 :生産リリース

これらのバージョンはすべて、アーティファクトに一緒に保存できます。プロジェクトは、コンパイル対象を正確に把握しています。

パッチについてgitは、あなたの友達です。レポをフォークして、などのパッチバージョン番号を入力しprojectA-3.2.1-FOR_PROJ_Bます。.1がパッチリリースと記述子を示していることに注目してください。これにより、プロジェクトでこれらの変更を後でマスターに戻すのも簡単になります。

ソースコードの場合、ビルドツールを構成して「ソースjar」を生成し、それを成果物のバイナリjarと一緒にデプロイできます。ほとんどのIDEはソースjar名を検索して、ソースを自動的にダウンロードできます。

ソースコードに近づかないもう1つの大きな理由は、プロジェクトAのビルドシステム、ツールチェーン、およびコンパイル時の依存関係に縛られていることです。プロジェクトBでビルドエラーが発生した場合は、まずプロジェクトAまたはプロジェクトBが原因でエラーが発生しました。プロジェクトAの場合は、そのプロジェクトの人を追跡してビルドを修正する必要があります。これにより、ビルドサイクルに多くのオーバーヘッドが追加されます。


最後の点を除いて十分に公平です。gitサブモジュールは、別のプロジェクトの正確なバージョンに依存していることを意味します。依存関係は他の変更と一緒に更新されることはないため、プロジェクトAまたはプロジェクトBへの変更が混乱を引き起こしたかどうかは常に明らかです。ご回答有難うございます!
mkalkov 14

1

バイナリ依存関係に行くでしょう。私を支持するあなたの考慮事項のほとんどは批評家なしです:

  • バイナリリポジトリマネージャがない場合は問題ありませんが、それを確立するのはそれほど難しいことではないと思います。最も基本的なレベルでは、使用するバージョンを決定する担当者だけが書き込むことができる共有フォルダー。

  • 別のプロジェクトのプレリリースバージョンに依存する必要がある場合:metacubedですでにカバーされています。ソースコードまたはバイナリの依存関係のいずれかを使用している場合は、プレリリース版であっても、安定したバージョンを使用する必要があります。もちろん、プレリリースに対して開発する場合、バグの解決のために、更新されたバージョンに切り替える必要が生じる可能性が高くなります。

  • 別のプロジェクトにパッチを適用する必要がある場合:チームが同じ家の別のチームから作成されたプロジェクトにパッチを適用するということですか?最も賢明な戦略は、他のチームにプロジェクトで抱えている問題を伝えることです。

  • IDEで依存関係のソースコードを参照する方が簡単だからです。依存関係の内部の仕組みを覗き見する必要はありません。

    • プロジェクトAの文書化が不十分
    • コーダーはプロジェクトAの「文書化されていない機能」の使用を終了しますが、更新時に事前の警告なしに消えることがあります。

1
社内プロジェクトにパッチを当てる:まあ、それは計画の問題です。私たちの場合、「社内」とは同じ組織を意味しますが、部門や地理的な場所が異なります。想像してみてください。プロジェクト(開発者)が新しい(バグの多い)機能を導入しています。私たち(プロジェクトB開発者)は、その機能に依存する新しいリリースを計画しており、プロセスの途中でそのバグを発見します。私たちのオプションは、(a)バグにパッチを適用し、予定通りにリリースしてパッチをアップストリームに送信するか、または(b)アップストリームにバグを報告し、次のスプリントが修正されるまで待ってから、リリースを1つのスプリントに遅らせます。オプションbは受け入れられる場合と受け入れられない場合があります。
mkalkov 14

また、JDKのソースコードを頻繁に閲覧していることがよくあります。これは、コーダーが改善され、世界クラスのドキュメントでも十分でない場合があるためです。ただし、これは、ドキュメントに記載されていないJDK機能を使用することを意味するものではありません。同じロジックが依存関係のソースコードに適用されます。しかし、これは誤用の余地を残すことに同意します。他のポイントをありがとう!
mkalkov 14

最初のコメントに関して、あなたのシステムは、チームAが「プロジェクトA 2014 v1」を起動し、チームBが「プロジェクトB 2014 v1」を起動するシナリオにつながる可能性があるようです。チームAが立ち上げたより...
SJuan76 '

これは、「チームAがプロジェクトA-1.2.3をリリースし、チームBがプロジェクトA-1.2.3-patch1を含むプロジェクトB-4.5.6をリリースする」に似ています。
mkalkov 14
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.