Drupal development uses configuration management, separate environments, and controlled deployment to move site changes safely from local work to live. Configuration management stores site settings in exportable files, environments give each stage of work its own copy, and deployment moves code and settings in a fixed order.
This matters for teams that also run WordPress, marketing sites, or client work. Content editors keep adding pages while developers change fields, views, and permissions. Without a clear workflow, a launch can overwrite content or lose settings.
Table of Contents
- What Drupal treats as configuration
- How should local, staging, and live environments divide work
- What is a reliable deployment sequence
- How do you handle content versus configuration
- What breaks most often, and how do you prevent it
What Drupal treats as configuration
Configuration is the structure of the site, not the content inside it. Content types, fields, views, menus, roles, and system settings count as configuration. Articles, users, and form submissions do not. Drupal can export configuration to files, usually in YAML format, so settings travel with code.
That lets developers review a field change the same way they review a code change. It also makes the live site rebuildable from version control plus the database. The split is not always clean. Blocks, path aliases, and some taxonomy setups sit near the line between structure and content. Decide early which items your team will manage as configuration and which editors control in the database.
How should local, staging, and live environments divide work
Most teams use three places: local for building, staging for review, and live for visitors. Local is disposable and can be reset often. Staging should mirror live closely, including similar modules and settings. Keep one source of truth for each kind of change.
Code and exported configuration move forward from local to staging to live. Content normally stays on live and is never overwritten by a lower environment. For content-heavy or SEO-sensitive sites, protect the live database during testing. Use sanitized copies downward when developers need realistic data. Never push a staging database upward unless you have a specific reason and a backup.
What is a reliable deployment sequence
A steady order prevents the most common failures. Test the same build that will go live, not a close copy. Put the site in maintenance mode only when the update truly needs it.
Keep environment-specific values out of shared configuration. API keys, file paths, and debug flags belong in per-environment settings. That separation avoids leaking test credentials to live.
- Commit code and exported configuration together.
- Deploy code to staging, import configuration, run database updates, then test.
- Back up live files and database before release.
- Repeat the same code deploy, configuration import, and database update steps on live.
- Clear caches and check key pages, forms, logins, and permissions.
How do you handle content versus configuration
Freeze structural changes while a release is in flight. If editors rearrange menus while developers export menus, one set of changes will lose. Short freezes and clear handoffs work better than merging by hand. Use core workflow tools for content staging when editors need review.
Draft, review, and publish states control when content appears. They do not replace configuration export for fields and views. For small reference changes, such as a new content category needed by a feature, create the item once and carry it with the release. Document who creates it and where. Ad hoc fixes made directly on live should be exported back down promptly or they will vanish in the next deploy.
What breaks most often, and how do you prevent it
Deployments often fail from mismatched configuration, skipped database updates, or files that were never committed. A view may reference a field that exists only on local. A module update may need an update hook that never ran. Watch for these warning signs: configuration imports that report differences after a clean deploy, user-generated files missing on live, and permissions that work for admins but fail for editors.
Each points to a step that lives outside version control. Reduce risk with small releases, readable change notes, and quick rollback plans. Keep backups you have actually restored from before. Confirm cache behavior after each release, especially for forms, search pages, and personalized blocks.
