複数のプロジェクトで使用されるライブラリを管理する方法は？
私の会社には、同じ共通ライブラリを使用するヨーロッパとアメリカの複数のオフィスで開発されたいくつかの製品が市場に出ています。この共通ライブラリは、業界固有の詳細の多くをまとめたものであり、拡張されたユーザーコントロール、拡張メソッド、演算ビットなどを追加しています。
QAがバグを抱えて戻ってきたとき、または製品の1つの製品の所有者が変更を求めているときに問題が発生し、そのバグまたは変更には共有ライブラリのコードの変更が必要です。これは、すべての製品で使用されるライブラリの変更であるため、変更は広範囲に影響を与える可能性があります。欠陥/バグレポート/変更リクエストは、通常、「オリジナル」製品の製品バックログに入れられます。つまり、QAによってテストされている製品、または変更を要求するPOによって所有されている製品です。つまり、他の製品ではこれらの変更に対する可視性がほとんどなく、ライブラリが他の製品で更新されると、（コンパイル時のエラーや、実行時の動作が微妙に変化することで）状況が悪化する可能性があります。他の製品のQAは、変更をリグレッションエラーとして認識する場合があります。
この時点でライブラリはかなり成熟しているため、行われる変更のほとんどはバグ修正の結果です。変更はプルリクエストを介して送信されます。各地方事務所の代表者が変更をレビューできます（ただし、承認する必要があるのは1人だけです）。影響が大きいことがわかっている変更は、通常は電子メールで通知されますが、特定のプロジェクトの開発が再開するときに忘れられることがあります。
QA製品の所有者と開発者の間で優れた可視性を確保するために、このようなライブラリをどのように管理できますか？
あなたの説明によると、共通ライブラリは、多くのプロジェクトに共通するビジネス機能とユーティリティのコレクションのようです。 1つの製品の変更によって引き起こされた回帰は、他の製品ではすぐに表示されない場合があります。
主な推奨事項は次のとおりです。
バージョン管理
あなたが言うように、ライブラリはかなり安定しています。このライブラリのバージョン管理をまだ行っていない場合は、副作用を防ぐための最初のステップです。リリースされると、バージョン管理されたアーティファクトはimmutableであると見なされます。
使用する各プロジェクトは、正常なバージョンのライブラリにロックする必要があります。 QAは、新しいバージョンのライブラリに更新することを選択した場合にのみ、変更の破壊について心配する必要があります。この時点で、彼らはとにかく完全な回帰テストを実行しているはずです。
Semantic versioning （major-minor-patch）は、互換性ベースのバージョン管理スキームであり、ケースに適用される場合があります。ライブラリのバージョンは、NuGetなどのアーティファクト管理ツールを使用して簡単に管理できます。ソースコードは、ブランチ、タグ、または同様のメカニズムを使用して維持できます。
リリースノート：バージョニングを使用すると、リリースノートの追加の利点があります。各バージョンは、そのリリースで行われたバグ修正と機能強化を説明できます。これにより、製品の所有者、開発者、およびQAにわかりやすくなり、情報に基づいた意思決定を行うことができます。
分解
履歴データに基づいて、ライブラリのどの領域に最も多くの変更またはチャーンがあるかについての良いアイデアがあるかもしれません。また、同じライブラリ内にかなり独立した機能領域がある場合もあります。
これらの領域を独立したライブラリとモジュールに分離し、それぞれに独自のバージョンとロックされた依存バージョンを持たせることをお勧めします。これは、バージョンアップグレードの影響を減らし、波及効果をより明確な領域に分離するのに役立ちます。
製品の所有者は、最も注意が必要なサブモジュールを追跡できるようになり、必要に応じて、特定の領域を管理またはQAするための専用チームを作成できます。
単体テストとe2eテスト
機能の「単位」を定義します。ほとんどのユーティリティでは、ユニットは単一のクラスまたは単一の関数です。場合によっては、モジュールである可能性があります。
単体テストを設計して、個々の機能をカバーします。 80-20ルール を使用して、最も多くのテストが必要なユニットを決定します。さらに、必要に応じてエンドツーエンドのテストを設計し、サンプルライブラリのコンシューマーをモックアウトして、予想される動作をテストします。
これは防御の最前線であり、互換性のない変更を行っており、バージョンを更新する必要があることを開発者に警告する必要があります。