Config Enforce: Simplify production deployments and manage your config like a pro!

Config Enforce

Simplify production deployments and manage your config like a pro!

Derek Laventure

derek@consensus.enterprises

Land Back!

Guelph and Waterloo are traditional territory:

Anishinabewaki ᐊᓂᔑᓈᐯᐗᑭ
Haudenosaunee
Attiwonderonk
Mississaugas of the Credit

I offer respect and gratitude to the people who are past, present and future caretakers of this land.

Where are you? https://native-land.ca/

I acknowledge that I live, work, and care for the lands and waters of Guelph, which are the traditional territory of the Anishinabewaki ᐊᓂᔑᓈᐯᐗᑭ, the Ho-de-no-sau-nee-ga (Haudenosaunee), and the Attiwonderonk (Neutral) peoples. This place is also connected to the Mississauga and the treaty and stewardship of the Mississaugas of the Credit First Nation.

As a settler whose family has been here for generations, my relationship to this place is one of learning and responsibility.

My commitment is to move beyond presence to active care—for the water, the land, and all its inhabitants.

This means putting my care into action by tending to the local waterways, supporting Indigenous-led justice, and continually deepening my understanding of what it means to be a respectful guest on these lands.

This reflection is a living practice, one I will carry with me as I walk beside the Speed and Eramosa rivers and contribute to the health of this place.

Consensus Enterprises

We help small teams do big things.

Gratitude

A brief history of production deployments
Drupal as application framework
CMI 2.0
Config Enforce
Demo
Q&A / Discussion

A brief history of production deployments

pre-Drupal 8

Config vs. Content -> all in the DB

Large mysqldump files

hook_update() functions

Pantheon-like workflows: DEV -> TEST -> LIVE

Features modules

Exportables

Clobbered production config values!

devs had local mysqldump files on their workstation
updates to config required custom hook_update() code to implement db schema changes as well as updates to variables/settings directly in the database.
If a relevant config had changed in production, the deployment would either:
- clobber the production value, replacing it wholesale
- hook_update would conditionally check for expected values before changing, and ideally handle granular updates as best we could
  - this would entail careful testing on the developer’s part, carefully setting up their local install to match the pre-update config, then iteratively running their hook_update() to ensure it properly handles all cases, which realistically is not likely to happen consistently
Pantheon-like workflows enabled us to refresh a “dev” instance relatively easily, and run hook_update() against known-production values, which helped to validate and troubleshoot deployment issues early. Still, it was a pain!
Reminder: in Drupal 7 we had the advent of Features modules, which were born out of a Drupal 6 itch the community had related to “packaging” config in a modular/reusable way

Configuration Management

drush cim/cex -> config distinct and exportable

Large config/sync YAML directories

(still) hook_update() functions

Config Split

Config vs. Content? not a clean line

Clobbered production config values!

Now we have config-import and config-export, enabling config entities to be distinguished from content entities, and commit exported YAML files to git repositories
Developers now pass around config/sync directories managed manually by cim and cex commands, often using config_split to allow for environment-indicator type customizations such as disabling email or visually flagging DEV vs PROD
- Caveat 1: we don’t tend to get very granular with config_split or the config-export mechanism, and most teams appear to simply commit the entire site’s config/sync directory into git at the outset, and track changes from there.
- Caveat 2: there is still a lot of “config” that lives in the database, as the distinction between what constitutes a “config entity” and a “content entity” is not always clear.
  - example: menu items, taxonomy terms, etc (see Structure Sync, Content Sync)
Deployments still rely heavily on hook_update()s to run smoothly (to update db schema or config entities) but we also need config-sync commands added to the deployment pipeline
- The problem of clobbering production values is still present! It’s a little bit easier to iteratively test a hook_update() that will avoid clobbering “drifted” production values, especially at a granular level (eg. a views.view.yml file that needs a new )
The problem of clobbering production values is still present! It’s a little bit easier to iteratively test a hook_update() that will avoid clobbering “drifted” production values, especially at a granular level (eg. a views.view.yml file that needs a new )

Drupal as application framework

(a small detour)

Sites with complex behaviour

Install profiles

CI/CD for automated testing

Grouping config into logical units

CMI 2.0

2018: Angie Byron collected ideas on CMI 2.0

1x Blog: Configuration Management with Drupal Distributions

Config Enforce

What if production config didn’t “drift”?

How it works

Disable config forms for those entities

Block API-level changes (`drush cset`)

In DEV, allow editing, and auto-export changes

Push exported updates to PROD

Enforce configs (`drush config-enforce:enforce`)

Config Enforce is 2 modules

Config Enforce (CE) - install in production

Config Enforce Devel (CED) - install in dev

Config Enforce disables forms (& blocks API changes)

Config Enforce Devel provides a UI to "register" configs to enforce

Config Devel

Config Devel enables automatic cim/cex

Config Enforce patches Config Devel with hooks

CED implements these hooks to tell Config Devel to import/export enforced configs

Config Devel does the actual writing to disk

Introspection

We use PHP reflection to invoke protected methods to access eg. getEditableConfigNames() methods.

Enforcement levels are lying!

But we’ve gained a really nice development workflow!

Resources

Project:
https://drupal.org/project/config_enforce
Docs:
https://config-enforce.consensus.enterprises

Drupal 11 and beyond

We need a consistent mechanism to identify config entities (to avoid Page manager spelunking)!

10.2 introduced #config_target in the form array uses Config Schema (issue)

Config transformation events

Config Filter now recommends using this new API instead!

Demo

Bootstrap project with Drumkit

Install and enable Config Enforce (enable patching!)

Basic settings & Default target module

Generate new target module

Enforce simple config (enforced by default!)

Enforce Fields, Views config

Generate from Active

Discussion / Q&A

Resources

Project:
https://drupal.org/project/config_enforce
Docs:
https://config-enforce.consensus.enterprises

Config Enforce

Simplify production deployments and manage your config like a pro!

Derek Laventure

derek@consensus.enterprises

Land Back!

Who am I?

Derek Laventure (he/they)

Consensus Enterprises

We help small teams do big things.

Gratitude

Table of Contents

A brief history of production deployments

pre-Drupal 8

Configuration Management

Drupal as application framework

(a small detour)

CMI 2.0

Config Enforce

How it works

Config Enforce is 2 modules

Config Devel

Introspection

Enforcement levels are lying!

Resources

Drupal 11 and beyond

Demo

Discussion / Q&A

Resources