跪拜 Guibai
← All articles
Frontend · Backend · Programmer

A VS Code Extension That Ships Frontend Builds to Linux in 30 Seconds

By 前端之虎陈随易 ·
Read original on juejin.cn ↗ Google Translate ↗ Alt translation

Frontend teams that haven't wired up CI/CD often still drag files manually or script fragile rsync one-liners. A VS Code extension that bakes in atomic swaps, automatic rollback via backups, and a visual progress panel removes the last excuse for cowboy deploys without adding infrastructure.

Summary

Simple Deploy turns the chore of shipping a frontend build into a single click inside VS Code. It connects to a Linux server over SSH, runs local build commands, packages the output, and uploads it — then backs up the existing deployment, extracts the new package to a temp directory, and atomically swaps it in. The whole pipeline is visible in a side panel with stage-by-stage progress and logs.

Configuration lives in project cards that pair a local workspace with a target server and remote path. Glob-based upload, delete, and retention rules control exactly which files move and which survive the swap. Pre-commands run sequentially before packaging, and any non-zero exit code halts the deploy.

The extension keeps the last 20 backups on the server and retains the last 100 deployment records locally. Password storage uses VS Code's internal encryption, and input fields filter shell metacharacters to block injection. The main limitation is SSH password auth only — no key-based login yet.

Takeaways
Deployments run as an 11-stage pipeline: pre-commands, local zip, SSH connect, backup, SFTP upload, verify, extract to temp, clear old files, swap, and cleanup.
Upload, delete, and retention rules all use glob patterns; retention rules override delete rules so directories like uploads/ survive each deploy.
Pre-commands execute sequentially before packaging, and any non-zero exit code aborts the entire deployment.
The extension keeps up to 20 timestamped backups on the server under ~/.static-deploy/.../backups/ and the last 100 deployment records locally.
Password auth only — SSH key authentication is not supported in the current release.
Remote paths must have at least two directory levels and cannot be system roots; inputs are filtered for shell metacharacters to prevent injection.
Only one deployment task runs at a time, and a failed deploy can auto-restore from the most recent backup.
Conclusions

The atomic swap pattern — extract to temp, then rename — is the same technique used by Capistrano and other mature deployment tools, repackaged for a VS Code sidebar. It's a small detail that prevents the half-deployed state where a site serves a mix of old and new files.

Requiring password auth and explicitly blocking SSH keys is an unusual tradeoff. It simplifies setup for beginners but will be a dealbreaker for teams that mandate key-only access or use bastion hosts.

The built-in backup and restore mechanism turns what is essentially a file-copy tool into something that can recover from a bad deploy without external tooling. Twenty rolling backups on the server is generous for a VS Code extension.

Concepts & terms
Atomic swap
A deployment technique where new files are fully extracted to a temporary directory, then the old directory is replaced in a single rename operation. This prevents the site from ever serving a mix of old and new files during the update.
Glob patterns
A syntax using wildcards like *, **, and ? to match file paths. In Simple Deploy, globs define which files to upload, which to delete before deployment, and which to retain even if they match a delete rule.
Pre-command
A shell command executed locally before the extension packages files for upload — typically a build step like npm run build. If the command exits with a non-zero code, the deployment stops immediately.
From the discussion

The deployment flow's backup-and-swap design earns praise for preventing broken live states. A competing view dismisses the extension's approach as overly complicated, arguing that a simple git push to a CI/CD pipeline achieves the same result with less friction. The first comment also pushes for stronger security via SSH keys and automated post-deployment health checks, while cautioning that monitoring live performance metrics after a deploy is critical to catch regressions like chunk-splitting misconfigurations.

The backup-to-temp-then-replace deployment flow is a robust design that avoids leaving the live site in a broken state during updates.
SSH key authentication is a necessary upgrade over password-only login for production security.
Automated health checks after deployment would make the tool more complete.
Post-deployment performance monitoring is essential to catch regressions like increased load times or JS errors caused by build configuration changes.
A simpler alternative exists: pushing code to a git server and letting a CI pipeline handle the server-side update automatically, making the extension's process seem unnecessarily complex.
Featured comments
向新出发叭 1 likes

This VS Code extension is quite thoughtfully made. The deployment flow of 'back up old code → extract to temp directory → full replacement' is designed very solidly, effectively preventing the problem of the live site being left in a 'half-broken' state due to deployment interruption. A few small suggestions for reference: 1. Currently it only supports password login. It would be better if SSH key authentication could be added later, since using password login in a production environment carries higher security risks. 2. If it could automatically trigger a simple health check after deployment (like curling the homepage to check the return code), it would be even more complete. I've used similar tools for frontend project deployment before, and deployment efficiency really improves a lot. But one thing to keep in mind: after deployment, it's best to check if there are any abnormal fluctuations in live performance metrics, like page load time, JS error rate, etc. We had a deployment once where the first screen time suddenly increased by 2 seconds, and later found out it was because the build configuration changed, causing unreasonable chunk splitting. If you use performance monitoring tools (like APM-type ones), keeping an eye on the dashboard data after deployment will give you peace of mind. Just personal experience, for reference~

See top comments, translated →
Source: juejin.cn ↗ Google Translate ↗ Backup ↗