チームベース開発のベストプラクティス

Pega Platform™の開発者は、アジャイルプラクティスを用いて、ブランチを活用して変更をコミットする共有開発環境でアプリケーションを作成します。

開発プロセスの最適化を行うため、次のベストプラクティスに従ってください。

• 複数の組み込みアプリケーションを活用して、より小規模なコンポーネントアプリケーションを開発します。 小規模なアプリケーションは、開発、テスト、およびメンテナンスが簡単になります。
• 複数のチームが1つのアプリケーションに属する場合、ブランチを使用します。 Branches explorerを使用して、ブランチの品質、ガードレールスコア、および単体テストを表示します。
• ブランチをマージする前にピアレビューを行います。 Branches explorerからレビューを作成したり、ピアレビューを割り当てたり、Pulseを使用してチームメイト共同作業を行ったりできます。
• Rule比較ユーティリティなどのPega Platform開発者ツールを使用して、ルールの競合に最適な方法で対処します。
• 不完全なものやリスクのあるものは、togglesを使用して非表示にし、継続的なブランチのマージを促進します。
• PegaUnitテストケースを作成し、予想されるプロパティ値とルールを実行して返される実際の値を比較することで、アプリケーションデータを検証します。

次の図は、複数の開発チームとシステムオブレコード（SOR）とのやり取りを示しています。

1. このプロセスは、チームAがシステムオブレコードに対してブランチレビューをリクエストすることから始まります。
2. ブランチレビュアーは最初に競合の検出をリクエストし、次に適切なPegaUnitテストを実行します。 ブランチレビュー担当者が競合を検出したり、PegaUnitテストに失敗したりした場合、レビュー担当者はブランチをリクエストした開発者に通知します。 開発者は、問題を解決するためにプロセスを停止します。
3/4. レビューで検出され、PegaUnitテストが正常に実行されると、ブランチはシステムオブレコードにマージされます。
5.その後、ブランチに関連付けられたルールセットバージョンがロックされます。
6. リモートチームBは、SORアプリケーションのルールを自分たちのシステムにオンデマンドで再ベースできるようになりました。 再ベースは、SORアプリケーションに加えられた最新のコミットを、チームBの開発者システムに取り込みます。

詳細については、「Development workflow in the DevOps pipeline」を参照してください。

次のシーケンス図では、FSGメールアプリケーションへの変更を例としてプロセスを説明しています。

アクター：

• 開発者：FSGEmailアプリケーションで新機能の実装を担当するエンタープライズ開発チームのメンバー。
• ブランチレビュー担当者：エンタープライズ開発チームのメンバーで、開発者によるコードレビューリクエストと、コードレビューが成功した場合にマージする役割を担います。
• Pega SOR：PegaインスタンスをSORとして設定します。 このインスタンスは、FSGEmailアプリケーションに最後に加えられた安定した変更のマスターです。
• Bookingアプリチーム：BookingアプリケーションとHotelアプリケーションを担当する開発チーム。

プロセス：

• エンタープライズ開発チームは、FSGEmailアプリケーションの新機能に関連する変更を実装します。
• エンタープライズチームの開発者は、システムオブレコードに対してブランチレビューをリクエストします。
• ブランチレビュアーは最初に競合の検出をリクエストし、次に適切なPegaUnitテストを実行します。
• ブランチレビュー担当者が競合を検出したり、PegaUnitテストに失敗したりした場合、レビュー担当者はブランチレビューをリクエストした開発者に通知します。 ブランチレビュー担当者は、開発者が問題を解決できるようにプロセスを停止します。
• レビューで競合が検出されず、PegaUnitテストが正常に実行されると、ブランチはシステムオブレコードにマージされます。 その後、ブランチに関連付けられたルールセットバージョンがロックされます。
• Bookingアプリチームは、SORアプリケーションのルールを自分たちのシステムにオンデマンドで再ベースできるようになりました。
• 再ベースは、SORアプリケーションに加えられた最新のコミットを、Bookingアプリチームのシステムに取り込みます。

アプリケーションを最初に開発する場合は、オープンなルールセットバージョンが必要であり、かつ望ましいものです。 ある時点で、分岐していないアプリケーションのルールセットが常にロックされたままになるように移行できます。

ブランチをマージする場合に、Create new versionとLock target after mergeを選択することで、再ベース操作を促進するオプションがあります。 ルールセットの常時ロックされたSORホストから再ベースをリクエストするシステムでは、再ベースまたはキャンセルの操作を進める前に、新しく作成されロックされたルールセットバージョンを検出します。