1

序章

Drools Guvnor には独自のバージョン管理システムがあり、実稼働環境ではアプリケーションのユーザーがビジネスの変化に適応するためにルールと意思決定表を変更できます。それでも、アプリの新機能が開発される開発バージョン管理システムには、同じアセットが引き続き存在します。

この投稿は、Drools ルールと Guvnor を使用する際のルール開発とデプロイに関する洞察/アイデア/経験を探すためのものです。

以下は、私が困惑してきたいくつかの重要な概念です。

Guvnor への展開

まず第一に、drl ファイルとデシジョン テーブルを本番環境に展開する最良の方法は何ですか? それらをzipパッケージに入れてから、Web-Davフォルダーに解凍するだけですか？Drools について調べてみましたが、一度に複数のファイルをインポートする方法が見つかりませんでした。ただし、ファクト モデルは jar アーカイブとして追加できます。Guvnor にはある種の REST API があるようですが、それを使用するにはカスタムのデプロイ スクリプトが必要です。

変更管理

第 2 に、アプリケーションが本番環境に入ると、ユーザーは、プレミアム クライアントなどの割引率を高く設定するために、デシジョン テーブルの値を変更する可能性があります。アプリのバージョン 2.0。

この時点で私たちが持っているのは

  • バージョン管理システムの drl ファイルとデシジョン テーブル
  • Guvnor によってバージョン管理された、ユーザーが変更した実稼働環境の drl ファイルとデシジョン テーブル

これで、Guvnor からルールとデシジョン テーブルを取得するところまで来ました。また、これには Web-Dav フォルダーが最適ですが、他にどのようなオプションがありますか?

今日のマージ ツールは、Excel ファイルの差分も処理できますが、大規模なプロジェクトではマージ地獄のように思えます。

ファクト モデルの下位互換性を維持する

もう 1 つのトピックは、ファクト モデルの完全性です。想定されるバージョン 2.0 の場合、開発者は常にリファクタリングを行い、ファクト モデル全体を逆さまにしたいと考えています。それでも、以前のバージョンに依存するユーザーが変更したルールが存在する可能性があるため、以前のバージョンとの下位互換性を維持する必要があります。これに関するヒントはありますか？ファクト モデルをシンプルかつクリーンに保ちますか? 事前に計画し、ユーザーが何を変更したいかを提案しますか?

概要

Drools と Guvnor を使用した展開と変更管理のオプションを検討したのは、私が初めてではなく、最後でもありません。したがって、私が聞きたいのは、これらの状況を処理するための最良の (そしてそれらを回避するための最悪の) プラクティスに関するコメント、ディスカッション、ヒントなどです。

ありがとう。

4

1 に答える 1

4

最善の方法は、特定のアプリケーションと作業環境に大きく依存します。しかし、以下は私自身の経験からの指針です。今のところ、いくつかのポイントを追加することに注意してください。物事が私に来るとき、私はおそらくこの答えに戻るでしょう。

最初の稼働後は、リリースを段階的かつ小規模に保つ

最初のリリースでは、いろいろ試してみる機会があります。この機会を利用して、できるだけ多くのリファクタリングを行ってください...

アプリケーションが稼働し、ビジネス ユーザーがデシジョン テーブルでルールを管理しています。あなたは、業界の人々が好んで「ビジネスの俊敏性」と呼んでいるものにおいて、大きな成果を上げてきました。残念ながら、これはアプリケーション開発の俊敏性を犠牲にする傾向があります。ガイド付きエディターのルールとデシジョン テーブルのルールはすべてファクト モデルに関連付けられているため、そのファクト モデルの既存のプロパティを変更すると、デシジョン テーブルが壊れます。最近のほとんどの IDE とは異なり、ファクトの getX() メソッドを右クリックして名前を変更し、そのプロパティに依存するすべてのコードが更新されることを期待することはできません。

デシジョン テーブルとガイド付きルールはリファクタリングが困難です。ファクトの名前が変更された場合、多くの (すべての?) バージョンの Guvnor で、そのルール/テーブルが開かなくなります。WebDav を介して基礎となる XML ファイルを取得し、テキストの検索と置換を行う必要があります。これを行うには、本番環境からテスト環境にファイルをダウンロードし、変更を加えてテストし、テスト環境に展開する必要があることを考えると、非常に難しいかもしれません。変更に満足したら、'プロダクション' Guvnor に戻す必要があります。残念ながら、あなたがそうしている間に、ユーザーが多くのデシジョン テーブルを更新したため、最初からやり直すか、過去 2 日間の変更を再度適用する必要があります。理想的な世界では、ビジネス ユーザーは一定期間ルールを変更しないことに同意します。

これを軽減するには:

  1. Guvnor 内で使用されるファクトは、アプリケーション ドメイン クラスとは別に保管してください。その後、アプリケーション開発者は内部アプリケーション モデルを心ゆくまでリファクタリングできますが、そのような変更はビジネス モデルには影響しません。2 つの間のマッピングを維持し、それらのマッピングをカバーするテストがあることを確認します。
  2. ファクトやそのプロパティの名前を変更するなどの変更は避けてください。作成するファクトとそのプロパティには、ドメインに適した名前が付けられており、これらがビジネスと一致していることを確認してください。一方、新しいプロパティの追加は比較的簡単です。ユーザーの将来の計画に目を向けるよう促すことは、十分に価値があります。
  3. 事実をできるだけ単純に保ちます。本当に必要でない限り、名前と値のペアよりも複雑にしないでください。1 つには、ビジネス ユーザーは、ルールの維持がはるかに簡単であることに気付くでしょう。Guvnor 内で管理されるものは、常にビジネス ユーザーが簡単に管理できるようにすることを優先する必要があります。
  4. 外部依存を事実から遠ざけてください。開発者は、簡単に永続化するために、ファクトに JPA @Entity としてアノテーションを付けるのは良い考えだと考えるかもしれません。残念ながら、Guvnor のクラスパスに追加する必要がある依存関係が追加され、再起動が必要になります。

ヒントとコツ

クロス環境の変更を行うための私の個人的な手法は、Eclipse を 2 つの Guvnor WebDav ディレクトリに接続し、ルールをローカル ディレクトリにチェックアウトすることです。ローカル ディレクトリでは、各ローカル ディレクトリが環境にマップされます。次に、Eclipse diff ツールを使用します。

Guvnor が管理するナレッジ ベースを構築するときは、事実のみを含み、他のものに依存しない別の Maven プロジェクトを作成します。このようにして、それらをきれいに保つのがずっと簡単になります。また、本当に依存関係を追加する必要がある場合 (つまり、可能であれば JodaTime を使用する場合)、すべての依存関係を含むシェーディング JAR を生成するステップをビルドに含めることができます。そうすれば、正しいバージョンの依存関係が含まれていることが保証される、1 つの JAR だけを Guvnor にデプロイできます。

と思うこともきっと増えてくると思います。私はこれに戻ってくることを忘れないようにします...

于 2013-11-15T12:55:48.990 に答える