How to manage Drupal configuration across environments with Features
Managing configuration across Drupal environments becomes predictable when the same exported artefacts move from development to testing and production. A Drupal Features module packages selected configuration—content types, workflows, views, blocks, roles, and permissions—into versioned files that developers can review and deploy with code. Teams then install a repeatable site capability instead of rebuilding every setting by hand on each server.
Features work best when configuration is treated as software rather than a trail of database edits. Git supplies the audit history, Drush performs imports and updates, and automated checks expose missing dependencies before release. This approach suits Australian agencies serving clients in Sydney, Melbourne, Brisbane, and regional centres, where staging infrastructure may be hosted in a different region from a developer’s local environment.
Environment-specific details still need clear boundaries. SMTP credentials, API keys, database addresses, payment gateway credentials, and production-only analytics identifiers should not be committed as ordinary Feature YAML. Keep secrets in server-side settings or a secret store, while the Feature owns reusable structure. That separation lets a site developed in Adelaide reach an Australian client without importing a developer’s mail server or a hard-coded Sydney office address.
Why configuration drifts between sites
Drupal separates configuration from content and code, but editors can still change configuration through the interface. A role may gain a permission, a view may gain a filter, or a content type may gain a field. Without an export workflow, development becomes the hidden source of truth and production gradually drifts away from the version the team believes it runs.
Drift causes failures that look unrelated to deployment. A missing view dependency can break a listing page, while a subtly different workflow can send an article to the wrong review state. A developer in Brisbane may add a field while a Sydney team edits the matching block manually; each change works locally, yet neither server matches the intended site.
Features reduce this ambiguity by making selected configuration a named, reviewable unit. They do not remove the need for environment planning, particularly when a Drupal installation connects to middleware or other enterprise systems. Background on integration layers from the Oracle Middleware blog can help teams identify which settings belong inside Drupal and which remain external dependencies.
Designing portable Feature modules
Design each Feature around one coherent business capability, not around whichever configuration happens to be dirty. An editorial workflow, event landing page, or customer account area may justify its own module. Smaller Features produce clearer diffs, make selective releases easier, and prevent an unrelated settings change from forcing an entire site rebuild. Dependencies on contributed or custom modules should be recorded explicitly and installed in every target environment.
Keep site-specific values outside the package where possible. Search endpoints, CDN hostnames, mail from addresses, analytics identifiers, and CRM credentials often differ between local, staging, and production systems. Exclude them from the Feature or place deliberate overrides in environment configuration. Secrets belong in access-controlled storage, while Drupal’s configuration system receives references that the application can use without embedding passwords in Git.
Module code and Feature YAML should follow the same review rules. Name modules consistently, avoid pulling transient operational state into YAML, and document any manual action required after deployment. Australian market projects may also need environment-specific consent labels, Australian Privacy Act settings, locally hosted integrations, or regional data-residency arrangements; retaining those differences as explicit overrides is safer than making a shared package nominally portable.
Exporting and reviewing changes
Create the Feature in a clean development environment, select the configuration entities it owns, and export them into a new or existing module. The Features interface can create dependency declarations and warn about missing modules, while Composer keeps the underlying Drupal project consistent. Review the generated YAML rather than accepting it automatically: field references, UUID links, and role permissions can reveal an accidental scope expansion.
Commit the Feature, its metadata, and any code changes in one branch, then compare them with the active site using drush config:status and Git’s diff tools. A useful release note explains what changed, which environments receive it, and whether content must be migrated separately. Import the same branch into staging before production; unresolved dependencies and overwritten local settings then surface while rollback remains straightforward.
Features configure Drupal behaviour but do not replace custom JavaScript or front-end implementation. For forms that need client-side enhancements, Drupalwoo’s AJAX form submission tips show how validation and submission can improve without hiding reusable settings in ad hoc scripts. Keep that behaviour in a versioned module and let the Feature own the configuration that the behaviour consumes.
Deploying Features through a release pipeline
A repeatable deployment starts with code and dependencies, followed by configuration and database updates. On supported Drupal versions, drush deploy can coordinate the release and any deploy hooks; otherwise, use a tested sequence such as composer install --no-dev, drush config:import --yes, drush updatedb --yes, and drush cache:rebuild. The exact order can depend on schema and module changes, so rehearse it against a production-like copy.
Do not import configuration blind. Compare staging’s active configuration with the repository, protect intentional local differences, and confirm that modules required by the Feature are enabled before importing dependent YAML. Database updates may create tables or fields that content later populates, while configuration imports may switch on new modules. Treat code, schema, and configuration as one release unit with a known state at each stage.
Australian operating hours add another practical consideration. Sydney and Melbourne observe daylight saving, Brisbane does not, and Adelaide sits half an hour out of phase; scheduling a release around local support coverage prevents an unexpected import from reaching a customer-facing site at the wrong time. Backups, health checks, and a tested Git revert complete the safety model. Reverting YAML is straightforward, but reversing a schema migration can require a separate recovery plan.
Choosing the right configuration workflow
Features and full configuration exports solve different problems. A Feature is useful for portable, reusable capabilities that teams want to own like code. A complete sync export is useful when a site must mirror almost every configuration item. Larger Drupal projects often add a configuration management workflow to protect production changes, stage them deliberately, and support environment overrides. The choice depends on team size, release cadence, and how much variation exists between environments.
| Approach | Best suited to | Main strengths | Main limitation |
|---|---|---|---|
| Features module | Packaging reusable site capabilities | Portable modules, explicit dependencies, reviewable YAML | Requires careful scope and dependency management |
| Full configuration sync | Mirroring nearly all active configuration | Complete snapshot with a simple workflow | Large diffs and greater risk of importing local overrides |
| Configuration management workflow | Selective deployment and environment overrides | Stronger safeguards for production configuration | More setup and process than a basic export |
| Custom deployment scripts | One-off or legacy migration requirements | Precise control over unusual changes | Harder to maintain, audit, and reuse |
For most teams, the durable pattern is to use Features for the boundary and ownership of reusable configuration, configuration sync for dependable transport, and continuous integration for verification. The Feature answers what the capability contains; the pipeline answers when and where it is installed. This separation produces auditable releases, reduces manual work on Australian support desks, and allows a production site’s configuration to be reconstructed from the repository.