好きですか？ はい、息をのむほどです。 それにもかかわらず、これらは、SberbankのUnified Frontal Systemの開発者の通常の就業日です。 200のチームが同時にプラットフォームの開発に携わり、プロセスの最適化と同期を目的とした複雑で重要なタスクを毎日解決しています。
同期と最適化について長い間話すことができます。このトピックは別の本に値します。 この記事では、小さな部分のみを取り上げます-統合対話の開発の最適化、経験の共有、そして何百ものシステムと統合し、誰も待たない方法を説明します。
そもそも私たちに関係する問題は、各チームが他の多くのチームに依存し、すべての期限を遵守して効率的に開発を行い、統合トレーニンググラウンドで隣接するシステムとドッキングするときに期待される結果を得るにはどうすればよいですか？
そして、2つの答えが見つかりました。1つの情報スペースと、開発と展開の最大限の自動化です。
現在、統合センターは「統合相互作用の統一登録簿」です。 レジストリには、すべてのサブシステムとサービスに関する情報、統合の相互作用の詳細、属性構造、データソースと使用法レジスタの説明、形式、プロトコル、および各相互作用の正確で明確な説明に必要なその他の特性が含まれます。 さらに、他の銀行システムの同様のレジストリに関連付けられています。 これらすべてが単一の情報スペースを形成します。
単一の情報スペースで、それは明らかですが、自動化はどうですか？ より多くのコードが自動的に生成されるほど、コストが低くなり、最終製品の品質が向上します。 統合相互作用の開発にとって、これは二重に重要です。個々に開発されたシステムの多くは、相互作用して相互に理解する必要があるためです。
ご想像のとおり、統合相互作用のレジストリは参照情報だけでなく必要です。 レジストリデータに基づいて、統合コンポーネント（統合レイヤー）の自動生成が行われます。 これにより、チームは追加のルーチン開発から解放され、単一の統合アーキテクチャを形成し、発表された契約に従って相互作用の調整を保証します。
はい、本当に便利ですが、それだけではありません。 チームはすべての統合をレジストリに組み込み、生成された統合レイヤーを受け取って停止しました。 チームが開発したモジュールの機能は、開発プロセスにある関連システムに依存しています。 になる方法 さらに、スプリントの最後に、プロダクトオーナーはチームの結果を確認したいと思うでしょう。 おそらく、利害関係者とともに、彼はいくつかのバックログの調整をしたいと考えています。 結局のところ、アジャイル。
どうする
そうです、不足している統合の相互作用をかき消す必要があります。 そして、すべてのチームが急いでスタブを書きました。
時間はひどく不足しています。最小限の労力で、やり取りをかき消すという大きな誘惑があります。 たとえば、呼び出し関数のコードに結果の戻り値を直接追加します。 完全に正直ではありませんが、同意しますが、個々のコンポーネントの作成、さまざまなメッセージブローカーの展開と設定に時間を費やす必要はありません。 はい、次のスプリントで多くを変更する必要があります。はい、隣接するシステムがこの実装と同様に動作するという保証はありませんが、時間がありません-スプリントを完了する必要があります。コストを最適化する時間はありません。
そして、ここで統合相互作用の統一された登録が助けになります。 統合コンポーネントの生成にすでに使用されている場合、開発およびデモ環境からアクセス可能な共通のインフラストラクチャに自動的に展開して、適切なスタブをすぐに生成することを妨げます。 また、これにテストスクリプトを作成するための別のツールを追加すると、開発者だけでなく、すべての相互作用を詳細に調べ、各サービスの形式、属性、ユースケースを十分に理解しているテスターまたはアナリストも作成できるようになります。 さらに、異なるチームによって作成されたテストスクリプトを共通のカタログに追加すると、実際の「スマートスタブ」が得られます。
スマートスタブESF
スマートスタブがJMSメッセージング標準をサポートするようになりました。 これにより、統合された正面システムと隣接システムとの相互作用のほとんどをエミュレートできます。 同時に、4種類の相互作用がサポートされています。
- ESF要求/応答外部スピーカー;
- ESFリクエスト/外部スピーカーからの応答なし（通知）;
- 外部スピーカーからのリクエスト/ ESFからの応答なし（通知）;
- 外部スピーカーからのリクエスト/ ESFからの応答。
応答テンプレートを選択するには、XPath表記を使用した着信メッセージの条件が使用されます。 指定されたテンプレートによる回答の生成は、FreeMarkerを使用して行われます。 XSDスキームによる要求/応答の検証がサポートされています。 すべての要求と応答はデータベースに記録されます。
上記で、スタブとテストスクリプトの主な開発者はテスターとアナリストであることを述べました。 アナリストは、統合相互作用の研究に直接関与し、サービスの属性構造、ユースケース、および呼び出しシーケンスを記述します。 テスターは、ユーザーストーリー（ユーザーストーリー）に基づいてテストシナリオを生成します。 これを念頭に置いて、スタブのすべての設定とテストスクリプトの作成は便利なWebインターフェイスを介して実行されますが、プログラミングスキルは必要ありません。 メッセージログの操作には、フィルタリング、呼び出しのリストの表示、各呼び出しの詳細情報への注意が払われています。 この機能は、スタブの動作を分析するとき、およびテストスクリプトの動作を理解するために必要です。
ここで、隣接システムの一部が準備ができており、一部が現在のスプリントでリリースされており、何かが後で開発されることを想像してください。 統合レイヤーの集中リリースにより、単一のパラメーター管理システム（CMS）からアダプターとスタブの構成を制御できます。 アダプターは、制御システムを介して実際のシステムまたはスタブと連携するように構成されており、アプリケーションを再構築することなく、再起動せずにリアルタイムで切り替えが行われます。
サービスモデルによってスマートスタブが提供され、チームが独自のインフラストラクチャを展開する必要がない（サーバーを探し、何かをインストールして構成する）ことを考えると、新しいスタブを作成して、数クリックで使用を開始できます。 納期が短い状況では、それは大きな助けになります。
スタブの開発を単純化することは、もちろん良いことです。 しかし、費用なしで完全に行うことは可能ですか？ 奇妙なことに、しかしはい。 プラグが開発されるほど、再利用の可能性が高くなります。 実装されたスタブの検索を簡素化するために、個別のレジストリがあります。 独自のスタブを開発する前に、この相互作用のためにすでに記述されているすべてのテストスクリプトのマスターシステムとサービスのレジストリを検索します。 必要なプラグが既に開発されている場合は、無料で使用できます。 そうでない場合は、現在のシナリオで何かを変更するか、新しいスタブを作成します。 すべての個別のテスト領域を使用できます。相互の影響を回避できるため、非常に便利です。
そして最後に
ESFの統合相互作用のための単一の情報スペースの導入と、統合レイヤーおよびスマートプラグの開発と展開の自動化により、コストを大幅に削減し、統合相互作用の品質と一貫性を向上させ、柔軟な（アジャイル）方法論を使用して多くのチームの同時開発を実行する機能も提供しました。
すでに多くのことが行われていますが、チームの要求と形成されたロードマップから判断すると、これはほんの始まりに過ぎません。 近い将来：
- サポートされているプロトコルと形式の拡張：http、kafka、json。
- 複数の呼び出しを含む複雑なテストシナリオのサポート、および単一のテストシナリオのコンテキストでの中間結果の保存。
- 外部サービスを呼び出し、その後のスタブでの使用のために実際の回答を記録する機能。
- 拡張エミュレーション機能のプラグインサポート。
多くのタスクがあり、すべてを昨日行う必要があります。 したがって、共同開発が奨励されます。 各チームは、スマートスタブまたはレジストリの機能を改良できます。 自分自身に必要な改善を行った後、チームはこれを他のすべての人に実装します。 ツールキットの共同開発により、製品の開発とロードマップの実装のタイミングを大幅に加速できます。
これについてどう思いますか？ 統合のトピックに親しみがあり興味がある場合は、投稿へのコメントをお寄せください。