Tagged: migrations
Pages with this tag
Continuous Develop & Deploy
1The everyday loop for a live CodeCanyon Laravel app — code, test locally, ship through the selected non-production target then production behind a database safety gate, and sync server-side changes back into git.
1 · Ship — code → test → deploy
2The everyday deploy loop (WF-SHIP) — decide small vs big, work on develop, clear the pre-deploy database safety gate (Atlas lint — STOP on DS102/DS103), then run develop → selected non-production target → production and tag the release.
1 · The decision rule
3Three questions that route any change to the right update-safe home — a ZajModule package, the vendor-customizations overlay, or a _zaj migration that adds marked columns to a vendor table — so nothing you build is lost on the next vendor update.
1 · Hotfix forward
4Branch from production state, make the minimal scoped fix, fast-track straight to production skipping staging, then back-merge so the fix survives the next release.
2 · Roll back
5Restore the last good release via the deployer symlink or a known-good tag — when to roll back versus fix forward, the database-migration caveat, and post-incident steps.
5 · Verify migrations & schema
6Confirm every migration ran (modules included), troubleshoot pending ones the right way, capture a normalized schema baseline for cross-environment diffs, then run the 11-point gate that proves the app actually works.
5 · Schedule, migrations + schema
7Install and verify the every-minute schedule:run cron with the provider path that fits the selected host, then verify migrations and export + diff the selected non-production schema against your local baseline.
Implement Vendor Updates
8Apply a new CodeCanyon vendor release without losing your customizations or breaking the database — compare the schema, apply the update on a branch, then restore your overlay.
1 · Compare the schema
9Diff the new vendor release against your frozen author-vX.X.X snapshot — list pending migrations, preview the SQL, run an Atlas schema diff, and classify every change by risk so a destructive operation never reaches the database by surprise.
2 · Apply the update
10Tag a backup, branch the frozen author baseline to author/vY.Y.Y, drop in the new vendor files, then merge to develop and run migrations safely — every step reversible until the update is proven.
Database & migrations
11How Laravel decides which migrations run, why additive-only discipline keeps vendor updates safe, and how schema-diff tools verify the database actually matches your intent.
Laravel/CodeCanyon — Handbook
12The mental models behind running a CodeCanyon Laravel app — when a change is a module vs a customization, where admin files live, how to extend the schema safely, and how to version your fork.