どうすれば「依存関係管理」を主張できますか？

私は現在、ビルド（ala Maven、Ivy、NuGet）の依存関係管理を採用し、共有モジュールの内部リポジトリを作成することを主張しています。このビルド手法の主なセールスポイントは何ですか？私がこれまで持っているもの：

• 共有モジュール、特にバージョンのアップグレードの配布とインポートのプロセスを容易にします。
• 共有モジュールの依存関係を正確に文書化する必要があります。
• ソース管理から共有モジュールを削除し、チェックアウト/チェックインを高速化および簡略化します_{（20以上のライブラリを使用するアプリケーションがある場合、これは実際の要因です）}。
• 組織で使用されているサードパーティのライブラリをより詳細に制御または認識できます。

私が見逃しているセールスポイントはありますか？改善の指標を示す研究や記事はありますか？

私はポジティブについて100％確信が持てません。ここにいくつかの欠点があります

1. 多くの場合、安定していない可能性のあるサードパーティのサーバー/エンドポイントに依存関係を追加することになります。

   bowerで、一部の依存関係のリポジトリが削除または移動されたことがありました。新しい開発者がやって来て、私のリポジトリのクローンを作成してタイプし bower install、アクセスできないリポジトリのエラーを取得します。代わりに、サードパーティのコードをリポジトリにチェックインした場合、その問題は解消されます。

   これは、実行しているサーバーに保持されているコピーからdepをプルする場合にOPが提案するように解決されます。

2. 初心者には難しい。

   コマンドラインの経験がほとんどない美術の学生と仕事をしています。彼らは、Processing、arduino、Unity3Dでアートを作り、ほとんど技術的な知識は必要ありません。彼らは私が書いたHTML5 / JavaScriptを使いたかったのです。バウアーのためのステップ

   1. githubからリポジトリのZipをダウンロードします（githubのすべてのリポジトリの右側にあります。gitを知らないためです）。
   2. ノードをダウンロードしてインストールします（bowerをインストールするためにnpmを実行できます）
   3. gitまたはmsysgitをインストールします（bowerはそれを必要とし、多くの学生のマシンにはインストールされていないため）
   4. バウアーをインストール（npm install -g bower）
   5. bower install （最終的に依存関係を取得するため）

   githubリポジトリにファイルをチェックインするだけで、手順2〜5をすべて削除できます。これらの手順は、おそらくあなたと私にとって非常に簡単に聞こえます。学生にとって、彼らは非常に混乱していて、すべてのステップと目的は何であるかを知りたいと思っていましたが、それは良い学習である可能性がありますが、クラスのトピックと完全に直交していて、すぐに忘れられた可能性があります。

3. それは引っ張るときに別のステップを追加します。

   それを何度も繰り返しgit pull origin masterてからコードをテストするとbower install 、最新の詳細を取得するために入力する必要があることを覚えておくのに5〜10分かかります。これはプルスクリプトフックで簡単に解決できます。

4. gitの分岐が難しくなります

   2つのブランチが異なる依存関係を持っている場合、一種のねじ込みです。bower install毎回入力できると思いますgit checkout。スピードについてはこれで終わりです。

あなたのポジティブについては、それぞれに反例があると思います

共有モジュール、特にバージョンのアップグレードの配布とインポートのプロセスを容易にします。

対何？配布は確かに簡単ではありません。20の代わりに1つのリポジトリを取得するのは簡単ではなく、失敗する可能性が高くなります。上記の1を参照

ソース管理から共有モジュールを削除し、チェックアウト/チェックインを高速化および簡略化します（20以上のライブラリを使用するアプリケーションがある場合、これは実際の要因です）。

逆に、修正のために他の人に依存することを意味します。depがサードパーティのソースから取得していて、バグを修正する必要がある場合は、パッチが適用されるまで待つ必要があります。さらに悪いことに、おそらく、必要なバージョンとパッチだけを取得することはできません。プロジェクトとの下位互換性がない可能性がある最新のバージョンを取得する必要があります。

あなたはそれらのリポジトリを別々にクローンすることでそれを解決できます、そしてあなたはあなたのコピーにあなたのプロジェクトの担当者を指すようにします。次に、修正をコピーに適用します。もちろん、ソースをリポジトリにコピーするだけでも、それを行うことができます

組織で使用されているサードパーティのライブラリをより詳細に制御または認識できます。

それは議論の余地があるようです。開発者がサードパーティのライブラリをの下の独自のフォルダに配置することを要求するだけです<ProjectRoot>/3rdparty/<nameOfDep>。使用されているサードパーティのライブラリを簡単に確認できます。

ポジティブがないと言っているのではありません。私が最後に参加したチームは100を超えるサードパーティの担当者でした。私はそれがすべてのバラではないことを指摘しているだけです。たとえば、自分のニーズに合わせてバウアーを取り除くべきかどうかを評価しています。

見てみましょう十二要因のアプリを起動します

特に、依存関係について彼らが言わなければならないことについて読んでください。優れた設計は、依存関係を特定するための宣言的なメカニズムを提供することに気づくでしょう。Javaでは、これは多くの場合Mavenを通じて実現されます。IvyとNuGetは問題なく動作しますが、Mavenは現在この分野のリーダーであり、Ivyは明らかに大変な作業です。

Mavenのリリースプロセス（正式なリリースの準備ができるまでスナップショットを開発し、以前のリリースを上書きしないでください。NexusやArtifactoryなどの適切なリポジトリマネージャーを使用してください）を遵守する場合は、適切に機能するビルドプロセスが必要です。

確実な宣言型ビルドプロセスが整ったら、Jenkinsとの継続的インテグレーション、Sonarを使用した継続的コード分析など、他の優れた実践への扉が開かれ、gitを使用したより優れたバージョン管理分岐戦略が求められます。

上記のそれぞれは、Mavenであるコアに基づいて構築されています。最近では、それはかなり簡単な決定です。

そして、トップ10リストの＃1アイテムは...

（ドラムロール）

すべての開発者は、すべての依存関係のまったく同じバージョンを使用してビルドするので、本番環境に何をデプロイするかを気にする必要はありません。