PracHub
QuestionsPremiumLearningGuidesCheatsheetNEWCoaches
|Home/Software Engineering Fundamentals/Atlassian

Design a CI/CD release notification service

Last updated: Mar 29, 2026

Quick Overview

This question evaluates object-oriented design skills, modeling of releases and changes, notification and event-driven system reasoning, and handling of deployment lifecycle concerns such as idempotency and version roll-forward behaviors.

  • medium
  • Atlassian
  • Software Engineering Fundamentals
  • Software Engineer

Design a CI/CD release notification service

Company: Atlassian

Role: Software Engineer

Category: Software Engineering Fundamentals

Difficulty: medium

Interview Round: Onsite

## 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)

Quick Answer: This question evaluates object-oriented design skills, modeling of releases and changes, notification and event-driven system reasoning, and handling of deployment lifecycle concerns such as idempotency and version roll-forward behaviors.

Related Interview Questions

  • Evaluate Architecture and Capacity Trade-offs - Atlassian (medium)
Atlassian logo
Atlassian
Jan 22, 2026, 12:00 AM
Software Engineer
Onsite
Software Engineering Fundamentals
3
0
Loading...

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)

Solution

Show

Comments (0)

Sign in to leave a comment

Loading comments...

Browse More Questions

More Software Engineering Fundamentals•More Atlassian•More Software Engineer•Atlassian Software Engineer•Atlassian Software Engineering Fundamentals•Software Engineer Software Engineering Fundamentals
PracHub

Master your tech interviews with 7,500+ real questions from top companies.

Product

  • Questions
  • Learning Tracks
  • Interview Guides
  • Resources
  • Premium
  • For Universities
  • Student Access

Browse

  • By Company
  • By Role
  • By Category
  • Topic Hubs
  • SQL Questions
  • Compare Platforms
  • Discord Community

Support

  • support@prachub.com
  • (916) 541-4762

Legal

  • Privacy Policy
  • Terms of Service
  • About Us

© 2026 PracHub. All rights reserved.