## CI/CD Release Notifier (OOD) You are designing an object-oriented component for a service that performs an automated CI/CD release every day. ### Requirements 1. **Each release has a deployment version** (e.g., `v1`, `v2`, `v3`, …). 2. **Each release contains multiple changes**, and each change has an **author** (e.g., Jason, Mike). 3. When a deployment **succeeds**, the system must **notify each author** whose changes are included in that release. - The notification should be a JSON-like payload. - Example (conceptual): Jason and Mike are included in `v1` → notify Jason and Mike with payload indicating version `v1`. 4. If a deployment **fails**, the pipeline automatically **rolls forward to the next deployment version** (e.g., `v1` fails → retry as `v2`). - Authors whose changes were in the failed deployment should still be notified when their changes eventually deploy. - In the follow-up deployment, the notification should still reference the version in which their change was originally scheduled (e.g., a change originally planned for `v1` that rolls into the next attempt should still be reported as belonging to `v1`). ### Deliverables - Propose classes/interfaces and their responsibilities (e.g., `Release`, `Change`, `DeploymentAttempt`, `NotificationService`, `Notifier`/`Channel`). - Describe the main flows: - recording a release and its changes/authors - handling success/failure - generating and sending notifications - Call out how you would handle: - **idempotency** (avoid double-notifying) - **multiple authors per release** - **retries / roll-forward versions** - extensibility (adding Slack/email/webhook channels)