Problem/Motivation

We want to add a mechanism to have different modules installed in different environments.
Core currently does not support this at all, but there is a contrib solution with config split.
The issue #3028179: Config Environment module (original issue) is where the work around this is happening. For most of the challenges we already have solutions implemented or planned. But there is one major issue for which we have to find a solution for this to work on real sites. This issue here is to discuss and find solutions for it so that the other issue can focus on implementing it.

A regular workflow looks like this:
In the development environment:

  1. update the code base with new versions of modules. (composer update)
  2. run update hooks
  3. export configuration

deploy code and config
in the production environment:

  1. update code base (composer install)
  2. run update hooks
  3. import config

The problem arises with update hooks of modules that are only installed in certain environments (most notably the production environment). This is because the update hooks of the production-only modules only run on production and thus may have effects on configuration that is then only modified in the active store in production. This of course then creates the challenge with the next step of the deployment which is the configuration import that would revert the changes the update hook has made. (and could possibly fail)

With config split one can overcome this by exporting only the production splits configuration with the special drush command just after the update hooks have run and before the config import.

Proposed resolution

TBD

Remaining tasks

find solutions
agree on what is best
Implement chosen solution in #3028179: Config Environment module (original issue)

User interface changes

n/a

API changes

n/a

Data model changes

n/a

Release notes snippet

n/a

Comments

bircher created an issue. See original summary.

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.0-alpha1 will be released the week of October 14th, 2019, which means new developments and disruptive changes should now be targeted against the 8.9.x-dev branch. (Any changes to 8.9.x will also be committed to 9.0.x in preparation for Drupal 9’s release, but some changes like significant feature additions will be deferred to 9.1.x.). For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

bircher’s picture

Version: 8.9.x-dev » 9.1.x-dev

Together with the other issues in this space this is the focus of 9.1. The issue can of course still be discussed now.

Version: 9.1.x-dev » 9.2.x-dev

Drupal 9.1.0-alpha1 will be released the week of October 19, 2020, which means new developments and disruptive changes should now be targeted for the 9.2.x-dev branch. For more information see the Drupal 9 minor version schedule and the Allowed changes during the Drupal 9 release cycle.

bircher’s picture

possible solutions that came to my mind over the last half year:

1) before running update hooks, snapshot the active config, and after the post update hook dispatch an event with the config names that changed as part of the update.
2) add schema versions to the configuration when exporting the environment configuration. Then ignore (import the active config) of the active environment if the exported version is too old. Or don't allow the import.

Version: 9.2.x-dev » 9.3.x-dev

Drupal 9.2.0-alpha1 will be released the week of May 3, 2021, which means new developments and disruptive changes should now be targeted for the 9.3.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.0-alpha1 was released on May 6, 2022, which means new developments and disruptive changes should now be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.5.x-dev » 10.1.x-dev

Drupal 9.5.0-beta2 and Drupal 10.0.0-beta2 were released on September 29, 2022, which means new developments and disruptive changes should now be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 10.1.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch, which currently accepts only minor-version allowed changes. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.