4

私は以前の仕事でこの問題に遭遇し、現在の仕事でも再び発生しました。つまり、運が非常に悪いか、この問題を解決できるツールまたは組織システムを認識していません。

どちらの場合も、最終製品はいくつかの独立したコンポーネントで構成され、それぞれが合意されたインターフェースを介して隣接コンポーネントと通信していました。問題は、時間の経過とともにインターフェイスが変更され、すべてが機能し続けるように、それぞれのコンポーネントも更新する必要があることです。

それ自体は問題ありません。問題は、SCM の履歴をさかのぼろうとすると、バグの追跡が非常に困難になることです。ある時点で、デバッグしようとしているコンポーネントがシステムの他の部分と互換性がなくなり、それらに対してテストできなくなるためです。それらをロールバックすることもありません。

次の例を見てください。

  1. クライアント/サーバー製品があり、簡単にするために、どちらも完全に動作する状態で開始するとします。これらのバージョンを client-1.0 および server-1.0 と呼びます。
  2. しばらくすると、バグ修正と機能が両方に加えられます。これで client-1.7 と server-1.2 になりました。
  3. サーバーのインターフェイスが変更されたため、クライアントも変更する必要があります: server-2.0 と client-1.8。
  4. バージョン 1.9 のクライアントでバグが見つかったため、以前のバージョンをテストして、サーバーで動作しなくなった場所を確認したいと考えています。ただし、1.8 を過ぎた場合は、サーバーも元に戻す必要があります。

私が提供するシナリオ例は非常に単純化されていますが、問題は次のとおりです。クライアントとサーバーのどのバージョンが相互に互換性があるかを強制する最良の方法は何ですか?

ドキュメントを通じてこれを行うことを検討しましたが、必然的に、人間の性質が勝利し、誰かが自分のコンポーネントまたは他のコンポーネントの更新を忘れます。バージョンを一致させることも考えました（つまり、サーバーが2.0になると、クライアントも昇格します）が、問題は、クライアントがサーバーとは関係のない他のコンポーネントの依存関係を持っている可能性があるため、意味がありません全体的にバージョンを更新します。

この問題を解決するには、何らかの解決策が必要です。誰か提案や私の研究の出発点はありますか?

4

4 に答える 4

1

履歴メタラベル（他のラベルを参照するラベル）を設定する必要があります

次のいずれかを実行できます。

  • SCM内のメタデータを介して（たとえば、SVNはメタデータとデータの履歴を保持します）
  • または、現在テストおよび検証されているすべてのラベルのリストを「連携」として登録する外部データベースを介して（リストも履歴に登録されている場合）

そのメタラベルの履歴化の性質により、システムをデバッグするために、以前の一貫性のあるラベルのセットに戻すことができます。

どのソリューションを選択する場合でも、実稼働環境で提供されたら、それを忘れないでください。

  • その実稼働環境にSCMがありません
  • したがって、展開された正確なラベルを思い出させるテキストファイルに依存する必要があります。

そのテキストファイルは、配信パッケージ（本番環境にデプロイするファイルのセット）をビルドするときに自動的に生成される必要があります

于 2009-01-29T09:20:44.193 に答える
1

依存関係の管理に問題はないようです。リグレッションに問題があります。

インターフェイスは依存関係の抽象化を処理し、単体テストとナイトリービルドは変更管理を処理します。

履歴リリースをテストする必要がある場合は、そのラベル付きバージョンをソースリポジトリから取得し、複製されたがまったく別の環境にデプロイできる必要があります。したがって、これはSCMでリリースラベルメタデータを定義し、スペア/専用ハードウェアを用意することです。

于 2009-01-29T09:23:50.257 に答える
1

RESTful インターフェイスを使用します。真の REST では、クライアントは、サーバーから返された応答のメタデータによってナビゲートする方法を学習します。メタデータを静的に保つことで、古いクライアントは新しいサーバー リリースに移動できます。

于 2012-02-02T07:05:46.830 に答える