私が働いている会社は、一連のアプリケーションを扱うソフトウェア ベンダーです。Webサービスも数多くあり、アプリケーションが変わっても安定していなければならないのは当然です。これは常に成功しているとは限りません。また、アップグレード後にサービスが以前と同じように動作していないことにお客様が気付くことがあります。
現在、これをより適切に処理したいと考えています。一般に、Web サービスは変更すべきではありません。変更する必要がある場合は、少なくともそのことを知り、変更を文書化します。
しかし、どうすればこれを保証できるでしょうか? アイデアの 1 つは、リリースごとに WSDL ファイルを以前のバージョンと比較することです。これにより、インターフェースが変更されないことが保証されますが、たとえば、共通ライブラリにバグが導入された場合など、動作の変更は検出されません。
もう 1 つのアイデアは、soapUI などを使用して一連のサービス テストを構築することです。しかし、十分なケースをカバーしたかどうかはわかりません。
これに関するベストプラクティスは何ですか?
Webサービスには、重大な変更と重大でない変更の2種類の変更があります。変更を壊すのは、Webメソッドの署名を変更したり、データコントラクトスキーマを変更したりするようなものです。重大な変更は、新しいWebメソッドを追加したり、datcontractにオプションのメンバーを追加したりするようなものです。一般に、クライアントは中断のない変更で作業を継続する必要があります。使用しているテクノロジーはわかりませんが、W3Cの推奨事項に従って、サービス名前空間とデータコントラクト名前空間でバージョン管理を使用しています。さまざまなエンドポイントでさまざまなバージョンをホストし続けることもできます。このように、クライアントが新しいバージョンのWSDLからプロキシを再生成せずに新しいバージョンのサービスを使用しようとしたり、古いバージョンを引き続き使用したりすると、クライアントは機能しなくなります。
一部のWCF固有のリンクは
http://msdn.microsoft.com/en-us/library/ms731060.aspx
http://msdn.microsoft.com/en-us/library/ms733832.aspx
振る舞いの変化をSOAの意味での変化とは考えていません。これは、欠陥を修正するようなものです。
サービスの最新の変更でサービス テストを更新し続ければ、サービスの安定性に間違いなく自信を持つことができると思います。これは、デプロイ前に人々が使用するベスト プラクティスの 1 つだと思います。
また、一般的には、サービスで使用されるコンポーネント (ライブラリ) を作成している開発者が単体テストをどれだけうまく行っているかが問題になると思います。これらの単体テストは、サービスで使用されているコンポーネントの変更に合わせて更新されていますか?
IMO では、WSDL の変更を監視することは別として (これは、意地悪な実装 ("promote-to-production") 戦略を使用している場合にのみ必要です)、すべてが確実に動作し、安定していることを確認する唯一の方法は、エッジ ケースを含む、WSDL と基礎となるアプリケーション機能の両方を完全にカバーするテスト スイートを使用して、継続的かつ自動化された定期的な機能テストを実行します。テスト ケースは、アプリや WSDL と同じようにバージョン管理する必要があり、アプリの新しいバージョンと並行して (後で反応としてではなく) 開発する必要があります。これはすべて SoapUI で自動化できます。理想的には、結果をどこかに記録して、ダッシュボードに蓄積して報告できるようにすることで、何かが壊れた場合にいつ壊れたかがわかります。うまくいけば、それをアプリケーションの更新などのイベント、またはサービスパックのプッシュ、電気工事の実行などのより良性のイベントに関連付けることができます.しかし...私が言うようにではなく、私が言うようにしてください. 私はこの戦略を職場で推し進めることに成功していません。あなたの投票は、私がもっと頑張るべきか、それとも何か他のことをすべきかを教えてくれます!