A proper staging-to-production workflow for CMS platforms prevents content editors and developers from making risky direct changes to a live site. This guide covers implementing this for Drupal/Joomla-based sites.
Why This Matters Beyond Code-Only Deployments
See How to Set Up a Staging Environment That Mirrors Production for general staging principles — CMS platforms add a distinct challenge: content itself changes independently of code, requiring your workflow to handle both code deployment and content synchronization thoughtfully.
The Core Challenge: Content vs Configuration vs Code
| Layer | Typical Source of Truth |
|---|---|
| Code (themes, modules) | Version control (Git) |
| Configuration (site settings) | Often exportable to version control (Drupal's Configuration Management) |
| Content (articles, pages) | Typically lives only in the database, edited directly by content teams |
Drupal's Configuration Management System
drush config:export
drush config:importDrupal has built-in configuration export/import specifically designed for this workflow — export configuration changes made in a development environment, commit to version control, then import into staging/production, keeping configuration synchronized across environments systematically.
Handling Content Synchronization
Content typically flows the opposite direction from code — rather than syncing content from dev to production, content is usually created/edited directly in a staging or production content environment, with periodic production-to-staging syncs (not staging-to-production) to give content editors realistic data for testing.
A Practical Workflow Pattern
- Developers make code/theme changes in a local/dev environment, committed to version control
- Configuration changes are exported and included in version control commits
- Deploy code + configuration to staging, test thoroughly
- Deploy the same tested code + configuration to production (content remains production's own, not overwritten)
Setting Up Automated Deployment for Code/Config
See How to Build a Simple CI/CD Pipeline with GitHub Actions — automate the code and configuration deployment portion of this workflow, while content remains a separate, direct-to-production editorial process.
Periodically Refreshing Staging with Production Content
#!/bin/bash
mysqldump production_db | mysql staging_db
rsync -av production_files/ staging_files/Regularly refresh staging's content/database from production (not the reverse) so content editors/testers work with realistic, current data — a common and useful practice, just be mindful of any sensitive customer data considerations if applicable.
Handling Content That's Genuinely Part of a Feature Release
For content that's genuinely tied to a specific feature/release (not just routine editorial content), coordinate its creation directly in the target production environment timed with the code release, rather than trying to migrate content between environments.
Testing the Complete Workflow
Verify your configuration export/import genuinely captures all necessary settings, and that your deployment process correctly handles the code+configuration deployment without inadvertently affecting existing production content.
Common Errors
Configuration import overwrites unexpected settings — review exactly what's captured in your configuration export scope; some settings may need to remain environment-specific (like API keys) rather than being included in the synced configuration.
Continue Reading
- How to Set Up a Staging Environment That Mirrors Production
- How to Back Up and Restore a Drupal/Joomla Site
- How to Build a Simple CI/CD Pipeline with GitHub Actions
Browse more articles in CMS Platforms Beyond WordPress.
