How Core dna caches pages, what makes a render fast, how code reaches a site and what stays behind, the go-live checklist, and running a site once it is live. For developers, leads and site operators who already build pages in a theme repository.
L2–L3
Unit 05 · Go-live
Rollback
Go-livePage 29 of 34Updated
Code can be rolled back in a minute; content, orders, payments and members cannot be rolled back at all. How to revert a release, what to do instead for everything else, and the procedure that makes the call on evidence.
Who this is for. The person named in the launch plan to decide on rollback, and the developer who carries it out. Afterwards you know what a revert undoes, what it cannot touch, and the order of questions that leads to the smallest undo that restores service.
"Roll it back" means different things for different parts of a site, and only one of them is quick and clean. Knowing which is which before launch day turns a stressful decision into a short checklist.
Code: revert, then push
A push to an environment's branch makes its folder match the pushed commit, then clears that environment's page cache, compiled templates and CDN copies of static files (what a push does). So rolling back code is a new commit that undoes the release, pushed like any other:
Shell
git checkout master && git pull origin master
git log --oneline --merges -5 # find the release merge
git revert -m 1 <merge-commit> # a new commit that undoes it
git push origin master # deploys it, and clears the caches
Do not reset the production branch to an older commit and force-push. It rewrites the history the next release is built on, and a revert does the same job in the same minute. Afterwards, merge the production branch back into the integration branch as after a hotfix, and fix the release on a branch. Then check the deploy log, or getLastVcsHash() in a page, to confirm the revert commit is the one live.
Records still point at the release's templates
Layouts, job actions and forms created for the release name its template paths (records point at code). A revert that removes a template breaks every page whose layout uses it, and empties every component that does. Before reverting, list the records the release added; move those pages back to their previous layout first, or revert only the part of the release that failed.
What cannot be rolled back
What
Why
What to do instead
Edits to pages, posts, books, forms and other versioned records
Change them back by hand from the release's list of records. The admin's audit log shows who changed which of them, and when
Settings and site data
Records without revisions, and not in the audit log
Change them back from the release's list; this is why that list records old values as well as new
Orders, invoices and payments
Real transactions with real customers and real money
Reconcile: refund or cancel through the provider and the admin, and contact the customers
Members, sign-ups and form submissions
Real people's data, created since the release
Keep them; fix forward
Emails sent, partner systems called by jobs
Already left the platform
Correct with a follow-up, and with the partner
A database restore from backup is possible only through Core dna, and it discards every order, member, submission and edit since the backup. It is a last resort for data that has been destroyed, decided with the client, never a way to undo a bad release.
On launch day only there is one more option: pointing the DNS back at the old site, if it is still running. Anything visitors did on the new site in the meantime stays on the new site and has to be carried across by hand, which is why a DNS rollback is for the first hour, not the first week.
The decision procedure
Name what failed: code (a template, a script, a build), configuration (a record), data, or something outside the platform (DNS, a provider).
Ask whether the main task is blocked: can visitors still buy, book, sign in or apply? If not, the clock is running.
Ask whether the fix is known and small. If it can be released as a hotfix within 30 minutes, fix forward.
Otherwise undo the smallest thing that restores service: unpublish the job, switch the payment method, make the page's previous revision live, revert the commit. Only on launch day, and only for a site-wide failure, point the DNS back.
Write down what was undone, when, by whom and why, and what has to be reconciled (orders, emails, partner records). The change then goes through the normal flow.
The person who decides is named in the launch plan, and the thresholds are agreed in advance (fix forward or roll back), so that the call is made on evidence rather than nerves.