Design of a Code Deployment System
Understand the high-level and detailed design of the code deployment system, including essential APIs, database schemas, and its evaluation for the functional and nonfunctional requirements.
We'll cover the following...
The previous lesson covered the fundamentals of the code deployment system: its requirements, resources, and key components. Now, let’s examine the high-level design of the code deployment system.
High-level design
The high-level design of the code deployment system shows the various components we identified in the previous lesson. We have started developing a solution to meet the functional and non-functional requirements with the following design:
The workflow of the high-level design is shown below:
Initially, users submit code to the
Version Control System (VCS) Tool for managing and tracking code changes across versions The VCS triggers the
Continuous Integration (CI Platform that automatically builds and tests code changes after each commit The code to build is placed in the pub-sub system. The code-build service takes code from the queue and converts it into a binary.
The generated artifacts (binaries) are stored in the primary blob storage.
Upon initiating deployment, the artifacts (binaries) from the blob storage are downloaded and installed on each machine in each region.
To better understand how the system operates at a functional level, let’s explore the API design next.
API design
The following are essential APIs required for the code-building and deployment process:
Code-build APIs
Let’s discuss some of the important APIs for the code-build process below:
Submit code: This API is used to submit code to a specified repository in the VCS.
submitCode(code, repository, branch, message)
The submitCode() returns the commit hash uniquely identifying the new commit within the specified repository. This commit hash is used to reference and retrieve the commit later.
The following parameters are used for this API:
Parameter | Description |
| The code submitted to the VCS. |
| This shows a path to a repository where the code is being submitted. |
| Within a VCS, a branch represents an independent instance of the primary code or repository, typically identified by a unique name. In our case, it shows the branch name where the code is submitted or edited. |
| An optional message during a commit. |
Trigger build: This API triggers the process of building and preparing the codebase for deployment.
triggerBuild(project_id, branch, commit_hash, configuration)
The triggerBuild() API initiates the build process asynchronously. So, this API returns without waiting for the build process to complete. It returns a JSON object containing the URL to the queue where it is placed, and the build_id assigned to the build.
Parameter | Description |
| The ID of the project for which the build is being triggered. |
| The branch name where the code is submitted. |
| A fixed-length hash value generated using SHA. |
| The specific settings, options, parameters, and environment variables that steer the course of the build process. |
Access build artifacts: This API is used to access the artifacts ...