Requirements

Functional Requirements:

• User management
• Code management
  • Integration with version control systems, like Github
• Build management system
  • Manual setup of build steps
  • Triggers for builds
• Test management
  • Integration with build
• Release management system
• Deployment management system
  • Slots
  • Rollback
    • History of deployments
• Environment management system
  • Configurations
  • Secret management
• Notification system
  • Email for start

Non-Functional Requirements:

• Scalable
• Automated
• Highly available
• Fault tolerance
• High traffic resistance

API Design

Each request would contain a Authorization header for the user using the system.

User management APIs:

• Add role: POST /users/{userUid}/{role}
• Remove role: DELETE /users/{userUid}/{role}
• Get user details: GET /users/{userUid}
• Update notification settings for user: PUT /users/{userUid}/notifications

Build management APIs:

• Start new build: POST /builds/{projectUid}
• Trigger build on code changes: POST /builds/{projectUid}/trigger
• Rerun build: POST /builds/{buildUid}
• Get builds: GET /builds/{projectUid}
• Get build details: GET /builds/{buildUid}

Test management APIs:

• Start new test run: POST /tests/{buildUid}
• Get build test runs: GET /tests/{buildUid}
• Rerun test run: POST /tests/{testUid}
• Get build test run details: GET /tests/{testUid}
• Get all test runs: GET /tests/{projectUid}

Release management APIs:

• Get release with deployments: GET /releases/{releaseUid}
• Run new release: POST /releases/{buildUid}
• Get all releases: GET /releases/{projectUid}

Deployment management APIs:

• Run deployment: POST /releases/{releaseUid}/deployments/{stage}
• Tie to environment: PUT /release/{releaseUid}/deployments/{stage}/{environmentUid}

Environment management APIs:

• Add environment: POST /environments/{environmentUid}
• Update environment: PATCH /environments/{environmentUid}

High-Level Design

System would contain a multitude of services: User service, Code service, Test service, Release service, Deployment service, Environment management service and Notification service.

Usage of a message broker would provide high scalability and eventual consistency with good fault redundancy. This will also provide the system with event-driven capabilities, which is fitting for this kind of system.

Since there are many services that connect to a message broker, it would make sense to utilize a serverless approach for services - e.g. Azure Functions.

Code handling - like e.g. PRs, merging and repo overview - are all done on the 3rd party providers.

User service would be the central service for user identity management and user roles/permissions configuration. Since consistency is required regarding users, storage should be a SQL database.

Code service is the central service that manages requests related to code. It connects to a blob storage where code is uploaded. After certain code events it publishes an adequate event to the message broker.

Build service is the central service for build management. All build requests go through here. It connects to a build DB, which can be a NoSQL DB for high scalability. This service would additionally react to any code events from the Message broker, check if adequate triggers exist and perform build action accordingly.

Test service is the central service for test management. All test request from client go through here. It connects to a No SQL test DB and keeps test configurations there. The service also reacts to any build events and fires adequate test runs based on the test configurations.

Release service is the central service for release management. All release requests from client go here. The service also reacts to any build events if no tests exist for the build or test events if tests exist for the build. The data for weather the service should react or not is held in the event itself. An entire history of releases and it's deployments is kept for a while, so that older deployments could be ran in case the current one broke something on the given environment.

Deployment service is tightly coupled to releases, since deployments are part of the release. Deployment service attempts to run a given deployment using container orchestration (e.g. Kubernetes). If the deployment is successful, the new version gets replaced from the container to the adequate machine and the previous version is discarded. If deployment fails, there is no replacement. Deployment states are kept in the same DB as releases. This system ensures safe deployment while also providing deployment history for needed version control and reversal to older versions.

Since the release and deployment services require large consistency, it's probably best to utilize a SQL database here. Concurrency handling is of high importance in this scenario, and any actions over release or deployments might lock some records or tables. If there are race conditions for e.g. deployment requests, they need to be handled gracefully. For start, first-come-first-serve approach might be fastest to develop, but later improvements are needed.

Notification service reacts to a multitude of events and sends notifications based on user settings. Notifications are sent over user's email.

Improvements

• Handle concurrency for release and deployments better.
• Implement custom Git repositories.

Tradeoffs

• Since the system is mostly controlled over a message broker, wait times for certain event-based functionality to trigger might be increased in high latency scenarios.
• Joining release and deployments together might require additional reads

Detailed Component Design

Deep dive into 2-3 key components. Explain how they work, how they scale, discuss tradeoffs, capacity, and any relevant algorithms or data structures.