タグ付けされた質問 「dependency-management」

静的ライブラリフォルダーとパッケージマネージャーの長所と短所を考えると、ライブラリフォルダーの方が良いアプローチだと思います。 ライブラリフォルダーで表示される長所： パッケージを管理するための外部ツールは必要ありません。 構築にインターネット接続は必要ありません。 ビルドの高速化（パッケージチェックなし）。 よりシンプルな環境（必要な知識が少ない）。 パッケージマネージャーで見られる長所： 複雑な依存関係ツリーを支援します（依存関係とそのすべての依存関係をダウンロードして管理できます）。 利用可能な新しいバージョンがあるかどうかを確認するのに役立ちます。 業界は、今日構築されているほぼすべてについて、パッケージマネージャーパスに従うことを決定したようです。だから、私は何が欠けていますか？

68 packages  dependency-management  package-managers 

2つの異なるコードベース（AndroidとNode.js Webアプリ）を使用した2つの主要な依存関係関連の危機がありました。AndroidリポジトリはFlurryからFirebaseに移行する必要がありました。これには、Google Play Servicesライブラリの4つのメジャーバージョンの更新が必要でした。同様のことが、HerokuがホストするNodeアプリでも発生しました。このアプリでは、実稼働スタック（cedar）が廃止され、cedar-14にアップグレードする必要がありました。PostgreSQLデータベースも9.2から9.6に更新する必要がありました。 これらのアプリの各依存関係はほぼ2年間古く、一部が廃止されて「日没」期間に達したとき、それらを更新または置換することは大きな頭痛の種でした。過去1〜2か月で30時間以上かけて、すべての競合と壊れたコードをゆっくりと解決してきました。 明らかに物事を2年間放置するのは長すぎます。特に、Herokuのようなプラットフォームプロバイダーを使用している場合、テクノロジーは急速に動きます。本格的なテストスイートと、Travis CIのようなCIプロセスがあり、更新から多くの当て推量を取り除くと仮定しましょう。たとえば、アップグレード後に関数が削除され、それを使用している場合、テストは失敗します。 依存関係を更新する頻度、または依存関係を更新するタイミング 強制されたため更新しましたが、何らかの先制的なアプローチの方が良いようです。マイナーバージョンがリリースされたら更新する必要がありますか？メジャーバージョン？更新が利用可能な場合、毎月ですか？どうしても犠牲になったような状況を避けたい。 PS-私の個人的なRailsプロジェクトの1 つでは、Gemnasiumと呼ばれるサービスを使用します。これは、セキュリティの脆弱性などを通知できるように、依存関係を追跡します。これは素晴らしいサービスですが、私が言及したプロジェクトの依存関係を手動で確認する必要があります。

30 dependencies  dependency-management 

10個のライブラリに依存するプロジェクトがあり、プロジェクトのトランク内では、これらのライブラリの任意のバージョンを自由に使用できるとしましょう。だから、私は最新バージョンから始めます。その後、これらのライブラリはそれぞれ月に1回（平均）更新されます。トランクを完全に最新の状態に保つには、ライブラリ参照を3日ごとに更新する必要があります。 これは明らかに多すぎる。通常、バージョン1.2.3はバージョン1.2.2のドロップイン代替品ですが、テストなしでは決してわかりません。単体テストでは十分ではありません。DB /ファイルエンジンの場合、古いバージョンで作成されたファイルで適切に動作することを確認する必要があります。GUIと関係がある場合は、すべてを視覚的に検査する必要があります。等々。 これをどのように処理しますか？いくつかの可能なアプローチ： 壊れていない場合は、修正しないでください。ライブラリベンダーが更新を発行する頻度に関係なく、アプリケーションで使用するときにライブラリに問題がなければ、ライブラリの現在のバージョンを使用してください。小さな増分変更は無駄です。 変更を小さく保つために頻繁に更新してください。いずれにせよいつか更新する必要があるため、いくつかのバージョンを飛び越えて潜在的な問題を蓄積させるのではなく、修正が容易なときに早期に問題に気付くように、頻繁に更新することをお勧めします。 間に何か。スイートスポットはありますか？

28 third-party-libraries  dependency-management 

TL; DR：Subversionではなく、Apache ArchivaやSonatype Nexusなどをアーティファクトリポジトリとして使用する理由は何ですか？ 現在使用しているビルドシステムには、ビルドへの入力と出力の両方として、多くのバイナリブロブ（イメージ、サウンドファイル、コンパイル済みバイナリなど）があります。これらを管理するシステムは非常にアドホックです。コードとともにSubversionリポジトリにチェックインされるものもあれば、正式なバージョン管理外の別の場所に保存されるものもあります。 私はこれを統合しようとしているので、より一貫性があり使いやすいものがあり、コードからバイナリアーティファクトを分離します。 Googleは、利用可能なアーティファクトリポジトリ（Archiva、Nexus、Artifactory、…）の選択があると言っていますが、読み返してみると、これらをSubversionよりも使用する利点はありません。それは私たちのためにバイナリの世話をします-それはすでにいくつかのバイナリのためにそれを行います、私たちはそれらをコードから分離するためにリポジトリレイアウトを再配置したいだけです-そして、すでにSubversionサーバーと専門知識を持っているという顕著な利点があります。 そう。Subversionのような一般的なバージョン管理ツールを使用するよりも、専用のアーティファクト管理システムを使用する利点は何ですか？

19 svn  dependency-management 

私はSOまたはここでいくつかの答えを探していましたが、結果なしで、あなたに尋ねる理由です。 アプリのサーバー部分とクライアント部分など、2つの異なるプロジェクトがあると仮定しましょう。私は自分のパートを開発していますが、友人は2番目のパートを作成しています。しかし、私たちの両方のようないくつかの共通のインターフェイスを使用する必要があるUserか、AccountInfoまたはChangableAccount順番に互換性を確保するために何でも...。たとえば、クライアントがユーザーデータをサーバーに送信する場合、サーバーは同じクラスで動作する必要があります。インターフェイスなどでも同じです。さらに、共通のインターフェイスに変更がある場合は、両方のプロジェクトでコードを新しい状況に合わせて調整する必要があります。 私が今見ることができる唯一の解決策は、すべての一般的なものが定義されている1つの余分なプロジェクトを作成することです。私たちと私の友人は、このプロジェクトをメインプロジェクト（クライアントまたはサーバー）への依存関係として追加する必要があります。共有プロジェクトは何らかのバージョン管理システムで管理できるため、常に最新の状態になります。 他にどのような解決策を提案しますか？このような問題はプロのアプリでどのように解決されますか？

17 java  dependencies  integration  dependency-management 

単一の（git）リポジトリに保存されている一連の関連する独立したC ++プロジェクトの編成に関するアドバイスをお願いします。プロジェクトはCMakeを使用します。 簡単な例として、2つのプロジェクトAとB、Bに依存するAを想定します。Aを開発するほとんどの人は、パッケージングシステムを介してBを取得します。したがって、Aのみをコンパイルします。ただし、開発者がAとBの両方を個別にコンパイル（およびインストール）できるようにする必要があります。 これが提案です： └── Repo1 ├── CMakeLists.txt (1) ├── A │ ├── CMakeLists.txt (2) │ ├── include │ │ ├── aaa.h │ │ ├── aaaa.h │ │ └── CMakeLists.txt (3) │ └── src │ ├── aaa.cpp │ ├── aaaa.cpp │ └── CMakeLists.txt (4) ├── B │ ├── CMakeLists.txt (2) …

12 c++  organization  code-organization  dependency-management  cmake 

私はこのようなプロジェクト構造を持っています： My Project - Other Team's Project -Third Party Dependency My ProjectOther Team's Project機能する必要があり、両方My Projectと機能Other Team's Projectする必要Third Party Dependencyがあります。これらを管理するために、依存関係管理システムを使用しています。 設計の観点から、My Project推移的に依存する方が良いThird Party Dependencyでしょうか？それとも、両方のために優れているMy ProjectとOther Team's Projectの両方に明示的に彼らが使用することを宣言しますかThird Party Dependency？ 他のいくつかのこと： 両方のプロジェクトに同じバージョンのが必要ですThird Party Dependency。 それらが異なるチームによって管理されているため、何も壊れないことを保証するためにテストされるOther Team's Project更新された場合は保証されませんMy Project。

11 dependency-management 

3〜4種類のオープンソースC / C ++ライブラリを使用するプロジェクトがあります。 これらのライブラリをいくつかのプラットフォーム用にビルドし、プロジェクトのさまざまなプラットフォーム用のインクルードファイルとスタティックライブラリをチェックインしました。 しかし、私はいくつかの問題に苦労しています。これらのプロジェクトはすべて、依存関係管理に関するものです。そして、私はベストプラクティスのアドバイスを探しています。 1）何を使用しているのか正確に知るにはどうすればよいですか？ 静的libのバージョンを取得する方法がありません。結果として、使用している静的libのバージョンを何らかの方法で追跡する必要があります（ビルド元のコミットのSHAである可能性があります）？ これらのライブラリをいつアップグレードするかを理解する必要がある場合、これは特に重要です。 2）ビルドを再現するにはどうすればよいですか？ 特定のプラットフォーム用の特定のライブラリーを構築するのに苦労したかもしれません。それを理解するのにしばらく時間がかかりました。 次回同じライブラリを作成する必要があるのは、半年後（なんらかの理由でアップグレードが必要になるとき）になる可能性があります。しかし、そのときまでに、何がどのライブラリで構築されたのかはっきり覚えていません長い間なくなります。 3）これらのライブラリをフォークしてソースコードのコピーを作成する必要がありますか？ これはそれほど問題ではありません。しかし、それはまだ問題です。ビルドが再現可能であることを確認するのは良いことです（そのようなソースコードが必要です）。

11 c++  c  builds  dependency-management 

バックグラウンド 特定の種類のハードウェアデバイスの使用状況に依存するプロジェクトがありますが、必要なことを行うのであれば、誰がそのハードウェアデバイスを作成するかは重要ではありません。そうは言っても、同じことをするはずの2つのデバイスでも、同じ製造元以外のデバイスでは違いがあります。したがって、インターフェイスを使用して、関連するデバイスの特定のメーカー/モデルからアプリケーションを分離し、代わりに、インターフェイスに最高レベルの機能をカバーさせることを考えています。これが私のアーキテクチャが次のようになると私が考えているものです： 1つのC＃プロジェクトでインターフェイスを定義しますIDevice。 別のC＃プロジェクトで定義されたライブラリに、デバイスを表すために使用される具象があります。 具体的なデバイスにIDeviceインターフェースを実装してもらいます。 IDeviceインタフェースは次のような方法かもしれないGetMeasurementかをSetRange。 アプリケーションに具象に関する知識を持たせ、具象をデバイスを利用する（実装しない）アプリケーションコードに渡しIDeviceます。 アプリケーションに影響を与えずに、使用中のデバイスを変更できるため（これは時々発生するようです）、これが適切な方法であると確信しています。言い換えると、具象の実装方法GetMeasurementやSetRange具象を通して実際に機能する方法は重要ではありません（デバイスのメーカーによって異なる場合があります）。 私の心の中で唯一の疑問は、今やアプリケーションとデバイスの具象クラスの両方がIDeviceインターフェースを含むライブラリに依存しているということです。しかし、それは悪いことですか？ また、デバイスとIDevice同じ名前空間に属していない限り、アプリケーションがデバイスについて知る必要がない方法もわかりません。 質問 これは、アプリケーションとそれが使用するデバイスとの間の依存関係を切り離すためのインターフェースを実装するための正しいアプローチのように思えますか？

10 c#  design-patterns  object-oriented  interfaces  dependency-management 

私たちは、相互に依存し合う多くのアプリとWebサービス（一部のパブリック向け製品、一部の内部およびプライベート「バックエンド」の一部）を持っています。これらの各コンポーネントには、4つの環境（特定の目的に役立つサーバー/ノードのクラスター）があります。 非生産 DEV-CIがプッシュ変更を構築する統合開発環境。エンジニアがローカルで再現できないバグを見つけるのに役立ちます QA -分離されたQA /テスト環境 DEMO -ビジネス関係者のための安定したUAT環境 製造 LIVE -私たちのライブ/制作環境 コードの昇格は次のようになります：（LOCAL開発者のマシン）=> DEV=> QA=> DEMO=> LIVE。 と呼ばれるmyappRESTful Webサービスによってサポートされるアプリケーションがありmyws、それ自体がと呼ばれるDBによってサポートされているとしmydbます。 現在、これらの依存関係の中で私が「オーケストレーション」プロモーションと呼ぶものmyapp-devがmyws-devありますmydb-dev。が使用するポイント。同様に、myapp-qaがmyws-qaを使用することを指すmydb-qa。同じのためにDEMOとLIVE。 これの問題は、たとえばにmyapp変更を加えるたびにmyws、mydbにも変更を加える必要があることです。しかし、各DEV環境は依存関係の環境を指しているため、DEVこれらの変更をすべて同時にスケジュールしてロールアウトする必要があります。さらに、1つのビルドが不安定になったり壊れたりすると、他の上流コンポーネントがダウンすることがよくあります。たとえば、開発者がを変更するときに何かを壊した場合、通常mydb-dev、myws-devおよびmyapp-devクラスターも不安定になります。 これを解決するために、私は「サイロ化された」プロモーション戦略と呼ぶものの提案をまとめます。すべてのコンポーネント間の依存関係はこのガイドラインに従います。 上流の依存DEMO関係は、すべての非実稼働環境（DEV、QAおよびDEMO）の下流の依存関係の環境に依存します。そして 上流の依存LIVE関係は、本番環境の下流の依存関係の環境に依存します この規則を使用myapp-devするとmyws-demo、実際にはをポイントし、を使用しますmydb-demo。同様に、およびmyapp-qaも指します。myws-demomydb-demo 私は見つけることができることをここに利点があるビルドの安定化：それははるかに少ない可能性が高いということであるDEMOコードはにそれを作ることができないので、特定のコンポーネントのための環境が不安定になるDEMOの両方の厳格なテストなしDEVとQA。 この方法で見つけられる唯一の欠点DEMOは、特定のコンポーネントで問題が発生した場合、すべての上流の依存関係のすべての非本番環境が突然破壊されることです。しかし、DEVとで実行されたテストのために、これが非常にまれに発生するはずであることに反対しQAます。 これはしていまし解決して、この問題とその解決策が既に（私が画策/サイロ化呼び出しています何のほかに）それらに名前を持っている場合、私は驚かないだろう多くの開発者（ずっと賢く自分よりも経験）という問題です。だから私は尋ねます：サイロ化されたプロモーション戦略のメリットはどんな短所よりも重要ですか、そして私がここで見落としているかもしれない短所は何ですか？

10 continuous-integration  release-management  dependency-management  environment 

最近、node.jsで遊んだ。 今、そこにあるすべてのノードのチュートリアルでは、 npm init そして、いくつかの標準的なサーバーフレームワークが必要だとすると、エクスプレスを選択するとします。 npm install express しかし、ASP.NETのような世界から慣れ親しんでいる多くのものが必要になります。 テンプレートエンジン（jade）とスタイルシートプリプロセッサ（SASS）について話します。 そして、彼らはあなたに「gulp / gruntをインストールしてください。そうすれば、サーバーを最小化、醜化して実行することができ、他の多くのものを自動的に実行できます！」 そして、それはgulp、node-sass、gulp-sass、gulp-uglify、そしておそらくもっとクールなもの（tsdまたはbabel、markdownなど）をインストールすることを意味します... しかし、それらすべては重いです、ディスクとプロジェクトます。同じことを問わず、すべてのノードモジュールが独自の依存関係を持っているため、10000以上のファイルは言うまでもなく、そのプロジェクト（まだ開始されていない！）の100 MB以上のディスクサイズで簡単に見つけることができます。依存関係は別のモジュールで使用されています。これは、Webサーバーはもちろんのこと、どこにでも移動するのが非常に困難です。 何か不足していますか？そのような明らかな欠陥が存在する間、ノード環境にそれほどの賞賛が与えられる可能性はないと思います。私が期待していることは多すぎます（結局、一度に多くのツールを使用しようとしたのですが）、ノードのベテランがこれを回避するために取るに足らないことはありますか？

9 node.js  dependency-management 

休業。この質問には、より焦点を当てる必要があります。現在、回答を受け付けていません。 この質問を改善してみませんか？質問を更新して、この投稿を編集するだけで1つの問題に焦点を当てます。 4年前休業。 通常、大規模なソフトウェアプロジェクトで実行時に発生する一時的な依存関係の問題にどのように取り組みますか？ 過去3週間、私はソフトウェアの別のコンポーネント内で大規模なソフトウェアのコンポーネントを開始しようとしましたが、実行時にのみ知られる一時的な依存関係の問題が原因で断続的に停止します。 一時的な依存関係の問題とは、特定のプロジェクトの依存関係の特定の依存関係が実行時に他の依存関係と衝突し、不安定性や瞬時の障害を引き起こすことを意味します。 何百、何百もの依存関係が使用されており、ツールに関連する約50のサブプロジェクトが他のチームによって分離されており、すべてのモジュールが相互に深くネストされた依存関係を持っています。プロジェクトの規模と複雑さを考えると、誰もがすべてのサブプロジェクトが何に使用されるのかを知りません。 この状況では、影響を受けるコンポーネントの依存関係ごとにDAGの視覚的な表現を生成し、実行時に衝突が発生する可能性のある場所を特定しようとしますか？他のサブプロジェクトで依存関係を管理する方法を制御できず、他の開発者が作成したJavaコードを変更できません 私が思いついたソリューションは、1〜2時間しか機能せず、その後、上流コンポーネントの変更により機能が停止します。上流コンポーネントの例は、私が取り組んでいるプロジェクトが依存する成果物であり、CIパイプラインの初期段階でビルドされます。 他の要求に応じて、使用されているテクノロジーに関する情報を含めます。情報が多すぎるために質問が閉じられたり、身体が長くなりすぎたりするリスクがあります。 Mavenは依存関係管理に使用されます。そして SpringはDIコンテナーとして使用されます。 依存関係の問題のほとんどは、実行時に読み込まれる他のモジュールのコンテキストの結果として、Beanコンテキストの重複を伴​​います 製品は適切に動作し、単体テストのスモールガスド、およびプログラムの機能的な正確さを逃れる統合テストがあります 一般的に、特定のプロジェクトの依存関係の可能なすべての組み合わせを列挙することなく、依存関係の競合を解決する方法を識別するための言語にとらわれないアプローチを探しています。 プロジェクトを再構築したり、品質ゲートを追加したり、会社全体のパラダイムシフトを推進したり、解決策として言語を切り替えたりすることはできません。

9 dependency-management  dependency-analysis 

Apacheには2つの別個のツールがあります。 Apache Maven Apache Ant + Apache Ivy 彼らは両方とも同じニッチを埋めているようです。2つの質問があります。 2つのツールの主な違いのハイライトは何ですか？ 2つの違いについて、本当に長い記事を書くことができると私は確信しています。詳細については探していません。 プログラミングの歴史-最終的に目的が非常に似ている2つの完全に独立したツールセットを作成するようにApacheが進化したのはなぜですか？

9 history  builds  dependency-management 

私は現在、ビルド（ala Maven、Ivy、NuGet）の依存関係管理を採用し、共有モジュールの内部リポジトリを作成することを主張しています。このビルド手法の主なセールスポイントは何ですか？私がこれまで持っているもの： 共有モジュール、特にバージョンのアップグレードの配布とインポートのプロセスを容易にします。 共有モジュールの依存関係を正確に文書化する必要があります。 ソース管理から共有モジュールを削除し、チェックアウト/チェックインを高速化および簡略化します（20以上のライブラリを使用するアプリケーションがある場合、これは実際の要因です）。 組織で使用されているサードパーティのライブラリをより詳細に制御または認識できます。 私が見逃しているセールスポイントはありますか？改善の指標を示す研究や記事はありますか？

9 dependency-management 

BがAに依存する異なるチームによって開発された2つの社内プロジェクトAとBがあります。両方のプロジェクトのソースコードはgitに格納されているため、プロジェクトAをサブモジュールとしてプロジェクトBに含め、ビルドシステムを構成しました両方を正しい順序で構築します。別の解決策は、ArtifactoryやNexusなどのバイナリリポジトリマネージャーを介してAを使用することです。 ソースコードに依存するか、バイナリアーティファクトに依存するかの長所と短所について疑問に思います。どちらが他より優れているのですか？これまでのところ、次のような要素を考え出すことができましたが、他の意見を聞くのはとても楽しみです。 ソースコードに応じてより良いです バイナリレポジトリマネージャーがない場合 別のプロジェクトのプレリリースバージョンに依存する必要がある場合 別のプロジェクトにパッチを適用する必要がある場合 IDEで依存関係のソースコードを簡単に参照できるため バイナリに依存する方が良い ビルド時間を最小限にする 別のプロジェクトのビルド環境をセットアップする手間を避けるため

9 builds  repository  dependency-management