Appearance
Release Management
Partner Documentation
DCS tracks two versions of every site — a Development version and a Production version — and manages the release between them from the portal's Release Management view.
How Releases Work
- Content and code changes accumulate against the Development version as pending changes.
- When you're ready, you Publish. DCS releases the pending changes and updates the Production version.
- The view previews the release tag and release branch for the promotion, and shows released and reverted changes for history.
Promotion is disabled while a deployment is already in progress, or when the site isn't currently eligible to release.
Versioning
DCS uses semantic versioning:
MAJOR.MINOR.PATCH| Type | When | Example |
|---|---|---|
| MAJOR | Breaking changes | 2.0.0 |
| MINOR | New features | 1.1.0 |
| PATCH | Bug fixes, content changes | 1.0.1 |
The portal manages the version numbers for you and previews the next release tag before you publish.
Branch Model
Deployments follow the branch model wired by dcs init:
| Branch | Environment |
|---|---|
release/** | Preview |
master | Production |
Work lands on a release branch and deploys to Preview; promotion moves the release to master for Production. dcs init generates the deployment workflow (.github/workflows/site-deploy.yml) — you do not hand-write it. See Deployment.
Promoting to Production
- Open the site's Release Management view.
- Review the pending changes listed against the Development version.
- Check the previewed release tag and branch.
- Click Publish and confirm in the "Promote to production" dialog.
DCS releases the pending changes and deploys the Production version.
Reverting a Change
Only pending (not yet released) changes can be reverted. Each change in the pending-release card has a Revert action:
- Find the change under pending changes.
- Start a revert and enter a reason (required).
- Confirm. The change is reverted and recorded under reverted changes.
Because managed text and SEO ship at build time in commit mode, the revert is applied as a tracked commit on the release branch.
Once a change has been released, it can no longer be reverted individually — roll the site back to an earlier version from Version History instead (see Releases & Version History).
Change History
The Release Management view separates changes into:
- Pending changes — accumulated against the Development version, not yet released.
- Released changes — included in a promotion to Production.
- Reverted changes — pending changes that were reverted before release, with their revert reason.
Troubleshooting
Publish Is Disabled
- A deployment may already be in progress — wait for it to finish.
- The site may not currently be eligible to release; check the view's status.
A Change Isn't in the Release
- Confirm the change was saved and appears under pending changes.
- Confirm you're viewing the correct site.
Deployment Failed After Promotion
- Check the GitHub Actions run for the site.
- Verify the build succeeds locally:
pnpm build. - If a bad change shipped, roll back from Version History, then fix and publish again.
Next Steps
- Deployment — Deployment workflow
- Development Requests — Automated changes
- GitHub Setup — Repository configuration