76 lines
4 KiB
YAML
76 lines
4 KiB
YAML
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: |
|
|
<p>Regardless of <a href="/daily/2024/12/23/how-many-environments-do-you-need">how many environments your application has</a>, you need to be able to move changes between them reliably.</p>
|
|
|
|
<p>You don't want to configure each environment and make every change by hand.</p>
|
|
|
|
<p>You want to automate this as much as possible so your changes are the same every time.</p>
|
|
|
|
<p>In Drupal 7, the Features module was used to export changes once and apply them again using a <code>features revert</code> command - although its original use case was to extract reusable features for different applications.</p>
|
|
|
|
<p>I've also written a lot of update of update hooks, like <code>mymodule_update_8001</code> to apply changes when database updates are applied.</p>
|
|
|
|
<p>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.</p>
|
|
|
|
<p>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.</p>
|
|
|
|
<p>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.</p>
|
|
|
|
|
|
format: full_html
|
|
processed: |
|
|
<p>Regardless of <a href="/daily/2024/12/23/how-many-environments-do-you-need">how many environments your application has</a>, you need to be able to move changes between them reliably.</p>
|
|
|
|
<p>You don't want to configure each environment and make every change by hand.</p>
|
|
|
|
<p>You want to automate this as much as possible so your changes are the same every time.</p>
|
|
|
|
<p>In Drupal 7, the Features module was used to export changes once and apply them again using a <code>features revert</code> command - although its original use case was to extract reusable features for different applications.</p>
|
|
|
|
<p>I've also written a lot of update of update hooks, like <code>mymodule_update_8001</code> to apply changes when database updates are applied.</p>
|
|
|
|
<p>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.</p>
|
|
|
|
<p>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.</p>
|
|
|
|
<p>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.</p>
|
|
|
|
|
|
summary: null
|
|
field_daily_email_cta: { }
|