異なるプロジェクトのanglejsコンポーネントのバージョン管理方法

Question

これは、技術的な問題よりも興味深い質問です。私の会社では、多くのanglejsコンポーネントを持つMVPを持っていますが、今は特定のニーズを持つさまざまな企業にMVPを提供しています。

ここでは、現実のシナリオでどのように見えるかです：

会社1

• モジュール1
• モジュール2
• モジュール3

カンパニー2

• モジュール3

会社3

• モジュール2
• モジュール3
• モジュール4（特定の機能または変更を有する）モジュール1（このプロジェクトのみ）

私たちは、私たちが話しているように、特定のコンポーネント機能のために異なる会社や支社の支店を使用しているため、将来のビジネスモデルに適合するバージョン管理システムを探していました。

これは地獄を見ることができます。メンテナンスは本当に難しく、異なるバージョンのアプリケーションを展開することはさらに困難です。

このケースの解決策を考え出すと、私の知見を共有することができてうれしいです。もしそうなら、私はブログ投稿を書くつもりです。

ありがとうございます！

Answer 1

プロセスガイダンスやツールの管理をお探しですか？

ツールの観点からは、npmをプライベートパッケージサービスで使用することも、専用のgitリポジトリを使用することもできます。バワーは同じことをすることができます。

Windowsのスペースには、あなたのリポジトリをホストできるNuGetがあります。そこにはサービスもあります。

Gitはサブモジュールとサブツリーをサポートしていますが、個人的には推奨しません。依存関係を実際のgit履歴の一部にするのは複雑です。

プロセスの観点から見て最大のことは、おそらく変更を破らないようにすることです。共有コンポーネントの設計に手間をかけずに済むので、共有コンポーネントの周りのすべてを再設計する必要はありません。なぜなら、最初に構築された方法ではうまく動作しなかったため、大幅に変更されたときです。

共有モジュールをオープンソースプロジェクトのように扱います。優れた文書化、コードのクリーンアップ、セマンティックバージョン管理の遵守安定版ビルドにバージョン番号を適用してください（gitタグで簡単にチェックアウトできます）。コンポーネントの変更を受け入れる担当者を置き、誰もがそれを使って何をしているのかを把握し、開発の指針とすることができます。

フォークそれは1つのプロジェクトが持っている要件の新しいパッケージには、他とは大きく異なっています。あまりにも多くの異なる要件を持つコンポーネントを維持することは悪夢になることがあります。