Code Backup and File Roaming
About 1048 wordsAbout 3 min
Cloud-native development environments use an on-demand approach with automatic destruction when idle.
To prevent the loss of uncommitted code and configuration files after the development environment is destroyed, cloud-native development adopts the following code backup and file roaming strategies:
Workspace Code Backup
There's no need to worry about losing uncommitted code in your workspace when the environment is destroyed. Cloud-native development employs two backup methods to ensure your code is not lost.
Tips
For team development, it's recommended to create personal branches for development. Each branch should be developed by only one person to reduce conflicts during code recovery.
Backup When Development Environment Is Destroyed
After modifying code in the current workspace directory /workspaces
, if you haven't committed your changes in time, don't worry about losing your modifications. When the environment is reclaimed, the modified code will be backed up. After rebuilding the development environment, uncommitted code will be restored to the workspace.
1. Backup and Recovery Method
Backup when the development environment is destroyed: Uncommitted code is backed up using
git stash
to a remote invisible branch, utilizing the repository's storage capability. Note: For the same user, this backup method only keeps one backup per branch, meaning it's an overwriting backup. If two cloud-native development environments are started for the same branch, the backup from the environment destroyed later will overwrite the backup from the environment destroyed earlier.Recovery when rebuilding the development environment: The backup code from the remote invisible branch is restored to the workspace using
git stash pop
.
Tips
Large files in the workspace may cause backup failure or slow backup speed. Try to avoid saving files larger than 100MB in the workspace.
2. Backup Content
- Uncommitted commits in the workspace
- Uncommitted code in the workspace
- Stashed changes in the workspace
3. Backup Code Deletion Timing
Each branch corresponds to a unique backup: Each environment's backup overwrites the previous environment's backup. Only the latest backup is saved for each branch, and the backup is deleted when the branch is deleted.
4. Recovery Strategy
When rebuilding or creating a new environment, it will always use the latest code, meaning the development environment starts with the latest code from the branch. During recovery, the latest backup will be restored. If code has been committed outside the cloud-native development environment, conflicts may occur. In this case, you can discard the recovered code.
Tips
After code recovery, the backup in the remote invisible branch will be deleted, meaning each backup can only be restored once. A new backup will be created when the new environment is destroyed.
The following content will not be backed up:
- Content declared in the
.gitignore
file - Modified content in subrepositories
- Modifications outside the workspace
Scheduled Backup Strategy
To avoid failures with the above backup method, cloud-native development also employs a scheduled backup strategy, periodically packaging and uploading uncommitted code.
- Backup: Every 5 minutes, uncommitted code in the workspace is collected, compressed, and uploaded.
- Download: You can download the backup code package from the "My Cloud-Native Development" list page.
- Deletion: The backup will be deleted when you delete the development environment history record on the "My Cloud-Native Development" list page.
Tips
- Files larger than 100MB will not be backed up.
- Backup code packages larger than 100MB will not be backed up either.
Non-Workspace File Roaming
Remote development supports file roaming for certain directories outside the workspace.
After the environment is destroyed and a new development environment is created, roaming files can be restored to the development environment.
Maximum roaming capacity: 64MB. Exceeding this limit will result in an error and prevent roaming.
Roaming Content
The following files or folders will roam by user dimension, effective for all projects (~
: the current user's home directory, generally the /root
directory):
~/.gitconfig
: Git global configuration file~/.local/share/code-server/User/settings.json
: WebIDE configuration file~/.local/share/code-server/User/snippets/*
: VSCode related configurations~/.cnb
: Users can add personal environment configuration files as needed in this directory.
Instructions for using the ~/.cnb
directory:
- Adding configuration files: If the repository needs to add a personal configuration file
.env.local
to store personal environment variables, you can add the.env.local
file in the~/.cnb
directory - After the environment starts, you can configure script tasks to copy or symlink
~/.cnb/.env.local
to the working directory (default is/workspace
),.cnb.yml
configuration as follows - Add the ignored file
.env.local
to.gitignore
to prevent personal configuration files from being committed to the repository
Example 1, copying files to the working directory:
To modify the roaming configuration file, you need to directly modify /root/.cnb/.env.local
# .cnb.yml
$:
vscode:
- name: vscode
services:
- vscode
stages:
- name: Copy .env.local file to the working directory (repository root)
# ./ is the working directory, default is /workspace
script: |
if [ -e "/root/.cnb/.env.local" ]; then
cp -f /root/.cnb/.env.local ./
else
echo "File does not exist"
fi
Example 2, symlinking files to the working directory:
To modify the roaming configuration file, you can modify /workspace/.env.local
in the working directory (symlink method will synchronize changes to the source file)
# .cnb.yml
$:
vscode:
- name: vscode
services:
- vscode
stages:
- name: Symlink .env.local file to the working directory (repository root)
# ./ is the working directory, default is /workspace
script: |
if [ -e "/root/.cnb/.env.local" ]; then
ln -sf /root/.cnb/.env.local ./.env.local
else
echo "File does not exist"
fi
Roaming Principle and Timing
Roaming timing:
When a user modifies configurations (such as settings.json) in the development environment, the modified content is not immediately roamed. Instead, it waits until the development environment is destroyed, then extracts the files that need to be roamed from the development environment for persistent storage.
How to restore roaming files:
When rebuilding the development environment, roaming files will be automatically restored to the development environment.
How to verify if files have been successfully roamed:
After modifying roamable files, to verify the effect of the modifications, you need to wait until the development environment is destroyed, then create/rebuild the development environment to see the roaming effect of the modified files.
Tips
Note:
- When multiple development environments are open simultaneously, the roaming content from the environment destroyed later will overwrite the roaming content from the environment destroyed earlier.
- Closing the development environment using
kill 1
will not successfully roam the files.