チームベース開発のベストプラクティス
システムオブレコードチームベース開発のベストプラクティス
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ホストから再ベースをリクエストするシステムでは、再ベースまたはキャンセルの操作を進める前に、新しく作成されロックされたルールセットバージョンを検出します。