Deploy commands

Resources · cheat sheet

The everyday deploy loop and the break-glass moves, command-for-command. Full narrative + checklists: Continuous Deploy and Emergency Hotfix.

Branch model

develop (work) → staging (test server) → production (live) → main (backup). staging and production are real servers; develop and main are local-only.

flowchart LR
  D["develop"] --> S["staging"]
  S --> P["production"]
  P --> M["main"]

The database safety gate (run before any deploy with migrations)

Non-negotiable. STOP on DS102 (DROP TABLE) or DS103 (DROP COLUMN) — back up the DB, get explicit approval, prove it on staging first.

php artisan migrate:status      # which migrations are pending
php artisan migrate --pretend   # the SQL each would run — no DB change
atlas migrate lint --env local --latest 1
# STOP if DS102 / DS103 appears. TRUNCATE is a hard block — manual approval only.

Ship — develop → staging → production

Small change (1–3 commits)

# 1 · confirm starting state (both range logs Expected: empty)
git checkout develop && git pull origin develop
git log --oneline develop..staging
git log --oneline staging..production

# 2 · commit on develop with a typed message
git add [files]
git commit -m "🔨 🟪 T3 Add-Feature: [description]"
git push origin develop

# 3 · run the database safety gate (above), then promote
git checkout staging && git merge develop && git push origin staging
dep deploy staging
# 👤 test on the staging URL before promoting

git checkout production && git merge staging && git push origin production
dep deploy production
# 👤 test critical paths on production (login, checkout, the change)

# 4 · tag + back up to main, return to develop
git tag -a v[VERSION] -m "[Description]"
git push origin v[VERSION]
git checkout main && git merge production && git push origin main
git checkout develop

Big change (4+ commits)

# branch first, build, then merge back into develop before promoting
git checkout develop && git pull origin develop
git checkout -b NewFeature/descriptive-name
# ...commit your work on the feature branch, push it...

git checkout develop && git merge NewFeature/descriptive-name && git push origin develop
# then run the database safety gate + the staging → production promotion above

Delete the temp branch only after 👤 confirmation.

Size	Definition	Path into git
Small	1–3 commits, simple change	Work directly on develop
Big	4+ commits, multi-file feature	Temporary NewFeature/... branch

Version scheme: first update after a major is vX.X.X-a, then -b, -c; a significant change gets a new vX.X.Y.

Server sync — capture server-side changes back into git

Run before a deploy when the server wrote files git doesn’t know about (admin-panel uploads, installer output) — the next deploy clears those paths otherwise. Preferred path is the ServerSync GitHub Action (capture-production.yml from the Actions tab); manual fallback:

ssh [SSH_PRODUCTION_ALIAS]
cd [DEPLOY_PATH]
git status      # if .env / *.key / *.pem / credentials appear, DO NOT stage them
git add .
git commit -m "🔄 ⬛ T5 ServerSync-Upload: Capture [description]"
git push origin production

Then review and merge back — never auto-merge a sync:

git checkout production && git pull origin production
git show --stat HEAD   # inspect the file list — no secrets, no surprise DELETED files
git checkout develop && git merge production && git push origin develop

Rollback — restore the last good release

Pick the lightest option that fits. A code rollback does not undo database migrations.

Situation	Command	Notes
The last deploy broke it	dep rollback production	~30 sec symlink switch to the previous release
You know the last good tag	dep deploy production --tag=v[LAST_GOOD]	List tags: git tag --list "v*" --sort=-v:refname | head -10
Go back several versions	Rescue branch (below)	When the options above don’t work

# Option 3 — rescue branch (full rollback)
git checkout -b rescue-from-v[LAST_GOOD] v[LAST_GOOD]
git push origin rescue-from-v[LAST_GOOD]
dep deploy production --branch=rescue-from-v[LAST_GOOD]
git tag rescue-$(date +%Y-%m-%d) && git push origin rescue-$(date +%Y-%m-%d)

Database caveat — a code rollback leaves the schema alone:

php artisan migrate:status
# Option A: roll back the last batch — ONLY if you're sure it loses no data
php artisan migrate:rollback
# Option B: restore from backup (hosting panel or your backup system)

Rolling back a migration deletes its data

If a migration added a column or table, migrate:rollback removes it and everything in it. When in doubt, restore from backup instead.

Hotfix — patch a live, broken app fast

The one workflow that skips staging on purpose. Branch from production (not develop), make the smallest fix, deploy direct, then back-merge so the fix survives the next release.

git checkout production && git pull origin production
git checkout -b Hotfix/fix-description
# minimal fix + quick local test
git commit -am "🔧 🟦 T2 Fix-Bug: Fix [description]"
git push origin Hotfix/fix-description

git checkout production && git merge Hotfix/fix-description && git push origin production
dep deploy production
# 👤 reproduce the original failure in a browser — confirm it's fixed

# make it permanent — back-merge to every branch
git tag v[VERSION]-[next letter]   # e.g. v1.0.0-a → v1.0.0-b
git push origin v[VERSION]-[next letter]
git checkout main && git merge production && git push origin main
git checkout develop && git merge Hotfix/fix-description && git push origin develop
git checkout staging && git merge develop && git push origin staging
git checkout develop

Fix forward vs roll back

If the last deploy broke it, roll back first (30 sec), then fix calmly. If the breakage is older or you already know the one-line fix, hotfix forward.

Related

Customization decision Where each kind of change belongs so it survives vendor updates.

Gotchas Per-env APP_KEY, APP_DEBUG, the vendor overlay, Cloudflare SSL.