Deployment
On Thursday night an editor fixes a typo in Friday's sale banner. How does that fix reach visitors, and if it breaks the page, how do you undo it?
This page shows how a change ships, how each response stays on one revision, and how to roll back. What a release, a draft and a preview are is in Releases and drafts.
How a change ships
Your block functions and your content live in your repository (see The .deco folder), so they ship together:
| Step | What happens |
|---|---|
| Commit | A developer, an agent, or an editor in the site editor changes a function, a saved block, or both. Review them in one pull request like any other change. |
| Build | The prebuild script runs deco schema && deco content && deco check: it bundles .deco/blocks into the build as the content module, and fails the build if saved content doesn't fit the code (see Checking content). |
| Deploy | Your host serves the new build. Every server of that build serves exactly one revision: the content of the commit it was built from. |
What a revision is
A release revision identifies one exact content map: deco content computes it as a hash of the whole map, so two copies of the content are the same exactly when their revisions match (see Snapshots and revisions). A revision never changes once it exists: change any saved block and you get a new revision. That makes a revision a safe cache key everywhere.
Publishing through Git
Commit changes to .deco/blocks on a working branch, review them in a pull request, and merge the approved changes into your production branch, usually main. Your next application deployment serves that merged configuration. In development, editing an existing file can update the local preview through your framework's hot module replacement; that preview is separate from the production publishing workflow.
Because content and code share one history, a content change is a commit like any other. That gives you:
- Review. A content change is a diff in a pull request, next to the code it needs.
- Branches. A content change can wait on a branch, with its own preview deployment, until it's ready (see On a branch).
- Rollback. Undo a change like any other commit (see Roll back).
Roll back
If Friday's banner breaks the page, redeploy the previous build: its content and code roll back together, so they always fit. To undo only the content, revert the content commit and deploy. Reverting a single code commit doesn't revert content committed after it; see Backward compatibility.
One revision per response
Content can change while a server is running: in development, when you edit a file, or with a loader that updates. Two reads a few milliseconds apart could then see different revisions; a header from one and a footer from the other make an inconsistent page. A client (what cms.forRelease() returns; see createCMS) prevents that: its first call picks a revision, and every later list and resolve on it, including concurrent ones, uses the same one. So make one client per request.
Follow-up requests from the browser may land on a newer revision. If data must match the HTML, render it in the same response, or send client.revision() with the page and read follow-up requests with cms.forRevision(revision).
A revision only selects content; it isn't a secret and unlocks nothing.
Hosted draft identity
A hosted draft client captures its local release and one draft overlay on first use. Its opaque revision identifies that pair; the draft pointer alone identifies only the overrides. Follow-up clients using the pointer may inherit newer local production. A served composite revision can be pinned only while the CMS retains that pair; it does not instruct the delivery API to fetch a matching base. See Draft overlays for fast previews.