2

状況は次のとおりです。

異なる場所にある2つのチームが同じ製品に取り組んでいますが、お互いのソースにアクセスすることはできません。1つのチーム-バックエンド（アプリサーバー）、もう1つのチーム-GUI（クライアント側）。

サーバーの要求/応答は非常に頻繁に変更されており、2番目のチーム（クライアント側）は、正気を保つことによって、プロセスの遅すぎることを知っていました。

私たちの目標は、プロセスの早い段階で問題を発見すること、またはバグが発生する前であっても双方の変更を発見することです。

私の考え：アプリサーバーでサポートされ、UIで使用されるすべてのjson応答/リクエストはxsdに変換され（jsonはxmlと非常に同等であるという事実に基づいて）、次のようなxsdが作成されます。1。サーバーサイドはすべてのビルド2を維持し、アクセス可能にします。クライアントサイドは（夜間のテストでも）自身を検証します。

2番目のアイデア： Apps erverには統合テストがあり（何らかの方法でそれらがあります）、たとえばファイルシステムに保存されているjsonコンテンツを含む要求/応答形式を検証します。次のステップとして、テストはjson形式が以前のテスト実行から変更されました。これらの統合テストを毎晩実行し、契約違反が検出されたら他のチームにメールを送信します。

これらの進行中の変更を追跡するための他の良いアイデアはありますか？

ありがとうイゴール

4

2 に答える 2

1

JSON スキーマを見てみましょう: http://json-schema.org/ 私は個人的にまだこれを試していませんが、これはまさにあなたが必要としているもののようです。

于 2013-03-17T16:05:04.630 に答える
1

あなたは、直接制御されていないシステムによって使用される公開されたインターフェースへの変更を管理するという古典的な問題について説明しています。

最初のアイデアはどちらも正しい方向に進んでいます。最初のアイデアは、クライアント チームが何が変更されたかを確認するための明白な方法があるように、サーバー チームが変更について通信する方法です。2 つ目は、通信が失敗した状況を把握して、エラーが本番環境の問題になる前に検出できるようにする方法です。

適切な人が適切なタイミングで変更について知ることができるように、この詳細を正しく把握することが秘訣だと思います。そのために、最初に作成したものに基づいて、いくつかの追加のアイデアを次に示します。

  • クライアント チームとサーバー チームの共同作業として、統合テストを維持します。その後、クライアント チームは、コードが行った期待を検証するテストを作成できます。サーバー チームは、変更をリリースする前に非運用環境でテストを実行できます。これは、クライアント チームが 1 つしかないことを前提としています。多くのサード パーティが使用するパブリック API に取り組んでいる場合、サーバー チームがクライアントのニーズを単純に推測する以外に方法はないかもしれません。これは理想的とは言えませんが、API が非常に単純で、考慮すべきユースケースがあまりない場合は、それでも機能します。

  • 重大な変更が迫っているときは、早い段階でクライアント チームに知らせて、生産上の問題を修正するために何かを機能させるために狂ったように争うのではなく、落ち着いてリラックスした方法で解決できるようにします。クライアント チームが対応できるようにコードがリリースされる前に、スキーマの 2 つのバージョンを調べて重大な変更を見つけることができるツールを作成すると、生成されたスキーマがこれに役立ちます。

  • 重大な変更と見なされるものと、クライアント コードが単に堅牢であることが期待されるものについて、クライアント チームと合意します。たとえば、既存のオブジェクトに新しいプロパティを追加することは重大な変更ではなく、クライアント コードは単純にそれを無視しなければならないことに同意することもできますが、それにはサーバー開発者側で新しいプロパティを決して追加しないという規律が必要です。別の既存のものの解釈を変更します。破壊的変更を構成するものについて合意すると、クライアント開発者はそれらの仮定に基づいてコードを構築でき、サーバー開発者は破壊的と見なされる変更に気づき、早期のコミュニケーションのためにフラグを立てることができます。

  • 特定のタイプの変更に対して複数段階の非推奨サイクルを有効にするメカニズムを実装します。たとえば、定期的にプロパティの名前を変更する場合、あるオブジェクト プロパティが別のオブジェクト プロパティのエイリアスであることを宣言できる機能をサーバー側コードに組み込むことができます。サーバーコードを作成してから、JSON ペイロードにプロパティの可能なすべての名前を一度に含めて、期待する名前に関係なくクライアントが機能するようにします。次に、エイリアスが一定期間維持されることをクライアント開発者に伝えることができます。その後、新しい名前を使用するようにコードを変更し、エイリアスを削除することができます。関連する戦略として、API に直接アクセスするのではなく、スキーマから単純なクライアント ライブラリを自動生成し、クライアント チームにそれを使用させるという方法があります。

上記のすべての戦略を適用して、私が維持している Web サービス API への変更を管理しました。それぞれの状況は異なりますが、うまくいけば、これらの考えが、あなたの環境で同様の効果を達成する方法についてのアイデアを与えることを願っています.

于 2013-03-17T16:18:41.100 に答える