跪拜 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 discussion splits between those who see the extension as solving a real problem and those who argue more automated, Git-driven CI/CD pipelines or platform services like Tencent EdgeOne make it unnecessary. A detailed critique acknowledges the extension's solid atomic deployment design but pushes for SSH key support, post-deployment health checks, and performance monitoring to catch regressions. The counterpoint is that not every project fits the idealized CI/CD model, so a simple VS Code tool has its place.

The extension's atomic swap-in design (backup, extract, replace) is a solid approach that prevents partial-deployment failures.
Password-only authentication is a security risk for production; SSH key support is needed.
Post-deployment health checks (e.g., curling the homepage) would make the tool more complete.
Deployment can silently introduce performance regressions like chunk-splitting changes that increase load times, so monitoring dashboards after deploy is critical.
Platforms like Tencent EdgeOne or simple Git-push CI pipelines already handle deployment automatically, raising the question of whether a manual VS Code extension is necessary.
Not every project environment supports idealized CI/CD; for some setups, a direct deploy tool is a practical fit.
Featured comments
向新出发叭 1 likes

This VS Code extension is quite thoughtfully made. The deployment flow of 'backup old code → extract to temp directory → full replacement' is designed very solidly, effectively avoiding the 'half-broken' online state caused by deployment interruptions. A few small suggestions for reference: 1. Currently only password login is supported. Adding SSH key authentication later would be better, since using password login in production environments carries higher security risks. 2. It would be more complete if a simple health check could be automatically triggered after deployment completes (like curling the homepage to check the response code). I've used similar tools for frontend project deployments before, and deployment efficiency really improves a lot. But one thing to note: after deployment, it's best to pay attention to whether online performance metrics have any abnormal fluctuations, like page load time, JS error rate, etc. We once had a deployment where the first screen time suddenly increased by 2 seconds, and later found 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. Personal experience, for reference only~

前端之虎陈随易

Thanks for sharing your valuable experience. [fist bump]

乘风不带尘

That's so much trouble. I just push to a git server and set up server-side CI to auto-update after a push.

前端之虎陈随易

You have to believe that not all projects are deployed the way we imagine. Existence is reasonable.

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