uuid: - value: 82f169a8-a9cf-4705-abaa-f8e29912aa9f langcode: - value: en type: - target_id: daily_email target_type: node_type target_uuid: 8bde1f2f-eef9-4f2d-ae9c-96921f8193d7 revision_timestamp: - value: '2025-05-11T09:00:03+00:00' revision_uid: - target_type: user target_uuid: b8966985-d4b2-42a7-a319-2e94ccfbb849 revision_log: { } status: - value: true uid: - target_type: user target_uuid: b8966985-d4b2-42a7-a319-2e94ccfbb849 title: - value: 'How easily can you move changes between environments?' created: - value: '2024-12-24T00:00:00+00:00' changed: - value: '2025-05-11T09:00:03+00:00' promote: - value: false sticky: - value: false default_langcode: - value: true revision_translation_affected: - value: true path: - alias: /daily/2024/12/24/moving-changes langcode: en body: - value: |

Regardless of how many environments your application has, you need to be able to move changes between them reliably.

You don't want to configure each environment and make every change by hand.

You want to automate this as much as possible so your changes are the same every time.

In Drupal 7, the Features module was used to export changes once and apply them again using a features revert command - although its original use case was to extract reusable features for different applications.

I've also written a lot of update of update hooks, like mymodule_update_8001 to apply changes when database updates are applied.

Since Drupal 8, we've had configuration management - a first-class way to export and import configuration changes - which I think was one of the best additions to Drupal 8, and something not available in some other CMSes, frameworks and applications.

There's an ecosystem around configuration management, including Config Split for per-environment configurations and Config Ignore to ignore sensitive information or changes you don't want to manage via imported configuration.

I recently worked on a project where we didn't have a CI pipeline running configuration imports on each change and things were very difficult to manage. Once that was in place, though, things were much easier, more consistent and changes were quicker to release.

format: full_html processed: |

Regardless of how many environments your application has, you need to be able to move changes between them reliably.

You don't want to configure each environment and make every change by hand.

You want to automate this as much as possible so your changes are the same every time.

In Drupal 7, the Features module was used to export changes once and apply them again using a features revert command - although its original use case was to extract reusable features for different applications.

I've also written a lot of update of update hooks, like mymodule_update_8001 to apply changes when database updates are applied.

Since Drupal 8, we've had configuration management - a first-class way to export and import configuration changes - which I think was one of the best additions to Drupal 8, and something not available in some other CMSes, frameworks and applications.

There's an ecosystem around configuration management, including Config Split for per-environment configurations and Config Ignore to ignore sensitive information or changes you don't want to manage via imported configuration.

I recently worked on a project where we didn't have a CI pipeline running configuration imports on each change and things were very difficult to manage. Once that was in place, though, things were much easier, more consistent and changes were quicker to release.

summary: null field_daily_email_cta: { }