リリースパイプラインの定義
2 タスク
20 分
シナリオ
Event Bookingアプリケーションの最初の本番デリバリーは、90日以内に行うことを目標としています。 Front Stageでは、年末まではアプリケーションの新機能や修正を毎日配信するつもりです。 Front Stageは、アプリケーションの頻繁な改良により、イベント予約市場での優位性を獲得できると考えています。 Front Stageのアーキテクチャーチームは、この目的を達成するためには、CI/CD（Continuous Integration/Continuous Deployment、継続的な統合/継続的なデプロイメント）モデルが最適だと考えています。 Front Stageは現在、自動化されたデプロイメント手法やテストツールを使用していません。
3人のデベロッパーから成るチームは、Front Stage本社でアプリケーションの初回リリースを作成します。 Front Stageでは、新機能の開発やバグ修正をサポートするために、ポーランドを拠点とする5人のデベロッパーを新たに採用する予定です。 Front Stageでは、Event Bookingアプリケーションを皮切りに、6〜9か月以内に分散型開発モデルに移行したいと考えています。 また、Front Stageでは、年末までにすべてのデベロッパーがローカルな環境で働くことを想定しています。
最初の本番リリースの後は新機能やバグ修正を毎日提供するというFront Stageのニーズをサポートするために、開発チームと環境を構成する、リリース戦略とプランを提案してください。
提案には以下を含めてください。
- アプリケーションの初回リリースをデプロイするために、開発チームの作業をどのように管理するかを説明する。
- CI/CDモデルに移行するためのアプローチを提案する。
- 2つのチームが分散環境でどのように連携するかを説明する。
詳細なタスク
1 ソリューション詳細のレビュー
初回リリースでは、Pega Communityで説明されている標準のリリースプロセスを適用できます。 この初回リリースでの開発とデプロイメントのタスクをサポートするために以下のタスクを実行します。
- Release Manager（ルールセットバージョン管理とスケジュール管理の責任者）のロールを担う人を特定する。
- サービス有効化スクリプティングのためのprpcServiceUtilsツールを使用して、環境間でルールを手動で移行する。 望ましい方法は、PegaのDeployment Managerを使用して初回リリースにパイプラインの自動化を実装することです。 しかし、このインフラはすぐさま利用できるものではありません。
- 自動化されたリリースパイプラインを実装する前に、非パイプラインモデルでブランチレビュー、ガードレール、単体テスト、ブランチとブランチルールセットを導入する。
初回リリース後は、Front Stageのアーキテクチャーチームと協力して、CI/CDを実装するための自動化パイプラインを開発します。
提案には以下のアクションを含めます。
- オートメーションサーバー、リポジトリ、CI/CDの経験者をチームに加える
- 使用するオートメーションサーバーとリポジトリを決定する
- オートメーションサーバーがPegaUnitなどの自動テストツールを呼び出す方法を説明する
- 自動化すべきリリースタスクと期間を特定する
提案には以下のアクションを含めます。
- パイプラインを監視するリリースマネージャーを特定する
- システムオブレコードで新しいルールセットバージョンとブランチを作成する人を特定する
- インポートの競合を処理するためのプロセスを決定して伝える
- 開発環境のリベースの頻度を伝える
- 通知やテストなどのインポート前後のタスクを確立し、継続的な統合プロセスを調整して改良する
2 ソリューション代案のレビュー
また、初回リリースでCI/CDモデルに移行することも提案できます。 Front StageはまだCI/CDモデルを導入していないため、この種の変更を実行しようとすると、90日以内にアプリケーションを提供するという目標を達成できなくなる可能性があります。 Deployment ManagerやprpcServiceUtilsユーティリティを使用して、個々のルールの単体テスト、テストスイートの開発、ルールのターゲット環境への配信を自動化して行うことができます。 このアプローチは、組織のCI/CDプロセスの成熟に合わせてデリバリーパイプラインを自動化するための準備となります。