Continuous Develop & Deploy

Workflow 2 of 5. Setup got your app live once. This is the loop you repeat forever after: change something locally, test it, ship it to staging then production with a database safety gate in the middle, and capture any server-side changes back into git before they drift away.

The whole point is safety through repetition — the same path every time, so a routine change never takes the site down and a logo someone uploaded in the admin panel never gets silently overwritten by the next deploy.

The everyday loop

flowchart LR
  A["Code locally"] --> B["Test at PROJECT.test"]
  B --> C["Commit on develop"]
  C --> D["DB safety gate<br/>migrate:status · Atlas lint"]
  D --> E["Deploy staging<br/>then test"]
  E --> F["Deploy production<br/>then test"]
  F --> G["Tag + update main"]
  H["Server-side change?<br/>uploads · installer · config"] --> I["Capture back to git<br/>WF-SYNC"]

Two jobs live here, and they point in opposite directions:

• Ship (WF-SHIP) moves your code outward — local → staging → production — and never crosses the database safety gate without checking.
• Server sync (WF-SYNC) pulls server changes inward — files an admin panel or installer wrote on the server, captured back into git so the next deploy doesn’t erase them.

When to reach for each

Situation	Use
You wrote or fixed code and want it live	Ship — page 1
Someone uploaded a logo / ran the installer / changed admin config on the server	Server sync — page 2
The site is down right now and you need a one-file fix fast	WF5 Emergency Hotfix (separate playbook)

Pages in this playbook

1 · Ship — code → test → deploy WF-SHIP. Decide small vs big, then run the develop → staging → production deploy sequence behind a pre-deploy database safety gate (Atlas lint — STOP on DS102/DS103).

2 · Server sync — capture server changes WF-SYNC. Pull untracked server / admin-panel changes back into git before a deploy wipes them — never staging secrets, always reviewing the file list first.

→Start here

Ship — code → test → deploy