モジュラーデプロイメント戦略
ルールセットを1つのケースタイプに特化することで、再利用を促進するのに役立ちます。 ルールセットを1つのケースタイプに特化させる理由には、以下のようなものがあります。
- 継続的統合（CI）のブランチベース開発を実現する。
- プロジェクトソフトウェアリリースを管理するためにAgile Studioのスクラム方式を使用してケース指向のユーザーストーリーを奨励する。
- 異なるルールセットから発生したルールを含むブランチを管理する。 このような場合、ブランチルールセットが生成され、生成されたルールセットは元のルールセットの名前をブランチ名の前に付けます。
- ブランチに複数のユーザーストーリーを格納する。
- ルールをブランチにチェックする際に、Agile WorkbenchのWork item to associateフィールドに入力する機能を簡素化する。
Agile Studio内でプロジェクトを作成すると、バックログのワークアイテムも作成されます。 基礎アプリケーションに組み込むアプリケーションを開発する場合、Agile Studioのバックログには、基礎アプリケーションのケースタイプごとにユーザーストーリーを事前入力しておくことができます。 Minimum Loveable Product（MLP）のリリースに適したケースタイプは、このバックログから選択できます。
PegaのDeployment Managerには、ブランチベース開発のサポートなど、CI/CDパイプラインを管理する方法が用意されています。 1つのブランチがプライマリーアプリケーションへのマージに成功した場合に、DevからQAへのデプロイメントを自動的にトリガーすることが可能です。 これを実現するには、そのブランチにチェックされたルールがプライマリーアプリケーションにのみ属する必要があります。
Case Designerは、同じアプリケーション内で複数のケースタイプの開発をサポートしますが、ケースタイプ固有のルールセット内にケースタイプクラスを作成すると、Dev StudioのCase Designerで生成されたルールがそのルールセットに追加されます。
ブランチベース開発のレビュー
アプリケーションブランチは、Dev StudioのApp Explorerで管理されます。
次の画像に示すとおり、ブランチを1つのケースタイプに特化する必要はありませんが、そうすることでブランチのレビュープロセスが簡素化されます。
ケース固有のルールセットのケース関連ルールがブランチに保存されると、ケース固有のブランチルールセットがまだ存在しない場合には生成されます。 ルールに影響を与えるCase Designer内での変更は、そのルールの分岐ルールセットのバージョン内で発生します。 ブランチルールセットが作成されると、アプリケーションのルールセットスタックの一番上に配置されます。
1つのブランチをマージするには、アプリケーションエクスプローラーの「Branches」タブで、ブランチ名を右クリックしてメニューを表示します。
マージプロセスの終了時に、「Keep all source rules and rulesets after merge」オプションが選択されていない場合、ブランチは空になります。 ブランチは、Agile Studioで定義された次の一連のタスク、課題、またはバグに使用できます。
Deployment Managerのブランチベースの開発
単一のブランチのマージがアプリケーションを正常に完了した場合に、別のオーケストレーションサーバー上で実行しているDeployment Managerアプリケーションが、自動的にデリバリーを開始するように設定されているシナリオを検討してください。 また、同じPegaDevOpsFoundationアプリケーション上に構築された開発環境アプリケーションが、RMURL（Release Manager URL）Dynamic System Setting（D-S-S）を設定して、オーケストレーションサーバーのPRRestServiceを指すようにしたとします。 単一のブランチのマージを開始する場合、開発環境はDeployment Managerアプリケーションにリクエストを送信します。 Deployment Managerアプリケーションは、開発環境内でのアプリケーションのパッケージ化、そのパッケージのDev/QA相互のリポジトリへの公開、およびそのパッケージのQA環境へのインポートを統制します。
アプリケーションのパッケージング
Application Packagingウィザードの最初の画面では、生成された製品ルールに含める組み込みアプリケーションとパッケージ化されたアプリケーションの確認が行われます。 コンポーネントは、pyMode = ComponentのRule-Applicationでもあることに注意してください。
同じルールセットを参照する複数のアプリケーションはできるだけ避けてください。 アプリケーションルールを新しい名前に保存すると、両方のアプリケーションにワーニングが表示されます（二重に参照されるルールセットごとに1つのワーニング）。
デプロイされる本番アプリケーションが、他の複数の組み込みコンポーネントアプリケーションに依存する場合は、デプロイメント戦略に違いが生じます。
製品ファイルにデプロイメントの一部としてDatabaseスキーマの変更が含まれ、組織のポリシーでDatabaseスキーマの変更の自動適用がサポートされていない場合は、ルールのデプロイメントを続行する前に、スキーマ変更用のSQLを生成して、DBAで手動実行する必要があります。
FSG Bookingアプリケーションの例について考えてみましょう。 最初にFSGEmailアプリケーション、次にHotelアプリケーション、続いてBookingアプリケーションがパッケージ化されます。
コンポーネントのみをパッケージ化したプロダクトルールを定義することは可能ですが、そうする必要はありません。 次の図に示すように、コンポーネントは、コンポーネントルール自体を使用してパッケージ化できます。
Deployment Managerは、pyMode = ApplicationとpyMode = Componentのルールアプリケーションインスタンスのパイプラインをサポートします。 アプリケーションがパッケージ化され、1つ以上のコンポーネントが含まれる場合、それらのコンポーネントもパッケージ化する必要があります。
パッケージングとデプロイメントに適用されるOpen-Closed原則
Open-Closed原則の目標は、波及効果を排除することです。 波及効果は、新しいインターフェイスを定義して既存のインターフェイスを非推奨にするのではなく、オブジェクトがそのインターフェイスに変更を加える場合に発生します。 FSGEmailやHotelなど、他のアプリケーションが構築されるアプリケーションのプライマリインターフェイスは、データの伝播を利用して新しいインターフェイスを構築するために必要なデータです。 EmailEditorコンポーネントが新しいプロパティを義務付ける場合、FSGEmailアプリケーションは、その上に構築されるHotelアプリケーションなどのアプリケーションへのインターフェイスを変更する必要があります。 次に、Hotelアプリケーションは、Bookingアプリケーションが新しい必須プロパティの値を指定できるように、組み込みインターフェイスを変更する必要があります。
アプリケーションを個別かつ依存度の高い順にデプロイすることで、最終的にはBookingアプリケーションの下のアプリケーションを破壊することなく、EmailEditorコンポーネントの変更がBookingアプリケーションで利用できるようになります。
補足： Bookingアプリケーションに関連するブランチを使用して、3つのアプリケーション（FSGEmail、Hotel、Booking）すべてを更新することは、ベストプラクティスではありません。
トレーニングを実施中に問題が発生した場合は、Pega Academy Support FAQsをご確認ください。