Recommended Usage of Workspace
# Recommended Workflow
- Create a development branch based on your needs.
- Enter the development environment corresponding to the branch and start coding. After committing the code, create a pull request and let the environment be automatically reclaimed.
- During code review, if code revisions are needed, restore the development environment from the development branch, make the necessary revisions, and commit the changes.
- Repeat the above steps until the code review is passed.
- Finally, when the merge request is merged into the target branch, delete the development branch.
If you have multiple features being developed simultaneously, repeat the above steps and keep each branch focused on one task.
# On-Demand Creation and Idle Time Reclamation
- Automatic reclamation:
- After the development environment is created, it will periodically check for activity.
If there is no activity within
10 minutes, it will be reclaimed. - If the VSCode page is opened and then closed after a period of development time,
if it remains closed for more than
10 minutes, it will be reclaimed.
- After the development environment is created, it will periodically check for activity.
If there is no activity within
- Maximum retention time:
16 hours. If the development environment remains active, it can be retained for up to 16 hours. - No overnight environments: To maintain scheduling availability,
if the usage time exceeds
12 hoursand falls within the4-6 amtime period, the development environment will be forcibly reclaimed.
# Roaming Strategy
# Workspace Code Modifications and Saving
If code modifications are made but not immediately committed, there is no need to worry about losing the changes. When the environment is recycled, personal configurations will be persisted, and they will take effect when a new development environment is created next time.
# Roaming of VSCode Configuration
If you modify the configuration in the VSCode page (e.g., changing the theme from light to dark), the personal roaming configuration will be saved when the environment is reclaimed. The next time a new development environment is created, the modified configuration will take effect.
# Uncommitted Code Backup Strategy
To avoid the loss of uncommitted code in the workspace, two backup methods (i.e., dual backups) are adopted to prevent the loss of uncommitted code.
# Backup During Development Environment Destruction
1、Backup and Recovery Methods
- Backup during development environment destruction: Commit the uncommitted code
to a remote invisible branch using
git stash, utilizing the storage capacity of the repository to achieve backup. - Recovery during development environment reconstruction:
Restore the backup code from the remote invisible branch to the workspace using
git stash pop.
Note: The presence of large files in the workspace may cause backup failure, try to avoid saving large files such as installation packages over 1GB in the workspace.
2、Recovery Strategy Explanation
- Rebuild the environment on the basis of the destroyed environment: Restore the backed-up code of the original environment.
- Start the development environment on a branch: Restore the latest backup code of that branch.
Note: After the code is restored, the backup on the remote invisible branch will be deleted, meaning that each backup of the code can only be restored once. A new backup will be generated when the environment is destroyed again.
# Scheduled Backup
- Backup method: Obtain the uncommitted code in the workspace every 5 minutes and generate a compressed package for upload.
- Download method: The backup code compressed package can be downloaded from the "My Cloud Native Development" list page.
Note:
- Files larger than 100MB will not be backed up individually.
- Backup code compressed packages exceeding 100MB will also not be backed up.