40

We had a drupalcamp a few months back and someone asked about managing deployments with the new config (CMI) system. One possible ideal workflow would involve keeping the config in version control and still being able to migrate configuration between team members.

The best that we in the room were able to figure out (partially based on the presentation at DrupalCon Portland) was:

  • Tell version control to ignore active config directory.
  • Copy all Configuration over to staging directory and commit to version control.

And use settings.php to reverse active/staging directory between the 2 environments. However, while figuring out a deployment workflow from one server to the next was complex but doable, what is the suggested workflow from multiple local environments (ie multiple developers) into dev (or between each other) - A possible issue would be every team member would be sharing the same or similar environment so how do changes on one teammate's machine come over?

Improve this question
7
  • 5
    I don't really agree with the current close votes. As CMI is a focus for Drupal 8, I think we can have some good answers here.
    – mpdonadio ♦
    Commented Sep 14, 2013 at 0:38
  • 3
    Agreed, this is the very good question. I believe the critical task drupal.org/node/1703168 is about this and other topics and is not yet completely resolved, so a answers here could help to push that issue forward.
    – Berdir
    Commented Sep 14, 2013 at 13:13
  • I apologize if my question came off as being negative towards the CMI initiative (which was not my intention at all). I have updated the question so it sounds more neutral.
    – btmash
    Commented Sep 16, 2013 at 21:00
  • 2
    i was almost going to say "Have you tried features". Maybe the "D8" should go in the question title? The "8" tag is a little invisible.
    – donquixote
    Commented Sep 18, 2013 at 13:06
  • 1
    Revised the title so question can be seen both by tag or via title :)
    – btmash
    Commented Sep 18, 2013 at 21:04

4 Answers 4

Reset to default
19
+250

After talking a bit with CMI maintainers, the discussion on what's the best approach isn't finished but the following is what makes the most sense at the moment.

Trying to keep it terse for now, will try to expand based on questions/when the referenced issue is resolved with an official answer.

So, first, the facts...

  • As already mentioned, there's the active and staging directory. Active is fully managed by Drupal, making changes directly in there (direct or indirect by switching to a different location) is not supported.
  • Staging is where Drupal looks for configuration to import and doe otherwise not care about it.
  • The import process is important, configuration changes can affect a site in a certain way and needs to be checked for validity. You can't change the field type of a text field to an entity reference, for example, that just doesn't work.
  • The config import always needs to run on all configuration, you can't import a single view or node type. It was tried, but trying to cope with dependencies, removes/renames and so on resulted in an very complicated system and it didn't work.
  • The only way to re-install default configuration, is to re-install that module. Which means that it would first try to remove all configuration (like fields). So that's not really an option. Manual, specific changes in update functions are possible but too tedious for this I think.
  • As the features module describes, it will be focused on providing re-usable functionality, not continuous deployments of configuration. This is what it was designed for in the first place.

Given that, the recommendation right now is to put the staging directory into version control. Each developer has then full control over what he puts there, either by copying the whole active directory over, or just a specific configuration file. The staging directory changes are then committed, pushed to production and the configuration import is run (in the UI or with drush).

Improve this answer
9
  • The staging directory in version control, I get that part. The other parts are what my mind is attempting to process. So if someone makes a change they copy their changes over to the staging directory and commit it. After that point, the other developers/next server gets the changes and their sync the changes over to the active directory. And rinse and repeat for any other server chain along the way (staging, production, etc). And it always goes through staging so there is no directory switch occurring anymore. Would that be accurate?
    – btmash
    Commented Sep 19, 2013 at 22:14
  • Yes. There must be no directory switching. Every configuration change must go through the import process or you might end up with broken site. For example, the list of modules is also configuration. Deploying it means modules need to be installed/uninstalled (Note: This does not yet work, but there's an issue to fix it).
    – Berdir
    Commented Sep 20, 2013 at 5:51
  • Ok, so even more questions now (split up into 2 comments) :) First, you mention modules are configuration. So even if a module is added to a repo and not enabled/disabled, it needs to be installed/uninstalled for just sitting there?
    – btmash
    Commented Sep 20, 2013 at 22:24
  • And the followup: (A) Will there be a mechanism to copy changes from the active directory -> staging (to simplify versus a person going into the config directory for these components - possibly a way to cherry-pick certain variables). (B) Does the staging directory get emptied out after the changes are synced from staging -> active? (B1) If so, then is the strategy from the devops standpoint to reset that directory prior to a git pull? (B2) If not, then is it correct to assume that while staging->active sync occurs, there shouldn't be any affect on configuration that has not changed?
    – btmash
    Commented Sep 20, 2013 at 22:26
  • The module installation status is configuration. Not the module itself :) That's what you deploy. a) There is an UI to download a tar.gz of the active directory, one to upload said tar.gz into the staging directory and one to actually do the Import, with overview and diff of the changes. B) I believe right now it is emptied, but I assume you can easily revert that with git. Not sure, easy to check. All that stuff is pluggable, so there could be a slightly different implementation that doesn't delete. B2) I don't get this one but I think yes.
    – Berdir
    Commented Sep 21, 2013 at 3:59
4

Great answered so far. Thanks you all!

We started a Drupal 8 project recently and implemented the following workflow.

We have three folders active, staging and export. Developers dump their to export. I don´t want to keep it in stageing. I thinks its easier to work with when the shared configuration is not directly stored in the staging folder. It´s just a felling i have no hard facts on this ...

Our current drupal 8 project template is available on github. I also wrote some handy drush commands to speed up the devleoper worflow. No manual copying from active to export required.

Improve this answer
5
  • 1
    So far, I agree with this approach. I have added all the features from the links in this post to the Drush config-export and config-import commands. I hope others will join me and @florian in exploring this 3 directory solution.
    – moshe weitzman
    Commented Jan 30, 2014 at 17:29
  • How do you deal with the sites/default/files/config_HASH config folder having a hash suffix, e.g. config_wNOLcmycPFZCrXJ9wis9dCdSR4lpYILdBsFxSWuK5Hzhcr
    – therobyouknow
    Commented Jun 17, 2015 at 14:47
  • @therobyouknow It is possible to override the location of these folders. Just look for "Location of the site configuration files." in settings.php I use the following snippet. This mean, the config is stored outside of Drupals root dir. $config_directories = array( 'active' => '../config/active', 'staging' => '../config/staging', );
    – webflo
    Commented Jun 18, 2015 at 15:39
  • Thanks @webflo I saw this. What would be the benefit of managing a code base and a config separately? I think this separation is a little artificial as both code and config (in yaml) determine the behaviour and are dependent on each other. In Drupal 7, configuration-in-code (or trackable by Git) was done with Features module creating a module for each particular config that was required to be tracked in code. In Drupal 8, there is Features 3.x which as I understand it, does the same but uses YAML to store the config and the generated modules are not dependent on the Features module.
    – therobyouknow
    Commented Jun 19, 2015 at 9:58
  • I think you misunderstood me, the config dir is still in git, but my Drupal site is not in the git repo root. The site is stored /web. So /config and /web are on the same level.
    – webflo
    Commented Jun 19, 2015 at 13:01
2

I haven't tried this yet, but my plan is to create a custom module that contains "default" config files containing only the configuration I care about. I believe other modules can contain configs that override other modules. (If not this should be made possible).

I think you must leave the config folder alone. Ignore it. It is auto generated on install from all of the individual modules' configuration files. The path is long and random. If you kept all of that in a repo, you would need a separate repo and you would be carrying along with it tons of default, unneeded config files.

Putting config in a custom module makes it a part of you main codebase.

The deploy process would be:

  1. Git pull or whatever to get new files.
  2. Clear caches.
  3. Reset default config. (From your custom module's files)

You can create custom modules (with it's own config) for each environment if you want.

Improve this answer
2
  • This sounds a great deal like features, doesn't it? Or is there a significant difference I'm missing?
    – Letharion
    Commented Sep 19, 2013 at 11:04
  • Its an interesting approach and I do like the idea. However, one of the largest advantages that has been mentioned as part of the CMI initiative is the ability to move over the config from the configuration directories. And from what I see, the settings.php file does allow you to dictate where the active/staging directories are (ie. they don't need to be auto-generated paths). Hence, I think a workflow with the current config should be possible without needing to create a feature as @Letharion mentions above.
    – btmash
    Commented Sep 19, 2013 at 16:48
2

Note: I appreciate that this isn't an answer in the strictest sense in relation to the question, but I've put it here anyway and I'll revisit and edit/delete once Features has an 8.x release and the dust has settled a bit more. This was just too big for a comment and I wanted to get my £0.02 in :-)

As a massive fan of Features, I'd suggest keeping an eye on the Features module's D8 incarnation.

Taken from the project page

3.x version of Features is planned for Drupal 8 to integrate with the new configuration management system. If you simply need to export simple site configuration, the D8 configuration management system should be used instead of Features. You will use Features in D8 to export bundled functionality (like a "photo gallery feature").

The way I kinda see it is that this idea makes it easier for dev teams to work on smaller parts of a site. I'm not going to go into a workflow yet though as there are still too many unknown variables, but I can't see it being THAT much different from a current Features deployment procedure.

I can't help but think yes, CMI is awesome; but most of my sites will still end up with Features modules (albeit a smaller amount due to not having to export EVERY content type, permission etc)

Improve this answer
4
  • While I do agree that features will slightly change its role and (hopefully) be the tool for bundling configuration components together (like the photo gallery feature you mention), configuration (as far as I understand) is still going to be maintained via the active configuration directory. So Features may solve a certain component but how the configuration directory workflow gets managed across environments is the real issue. The deployment procedure is slightly different from the current features deployment procedure primarily since the activestore data is in the db and datastore is files.
    – btmash
    Commented Sep 19, 2013 at 22:21
  • ...the d7 features deployment procedure involves activestore data in database and datastore in files. We are shifting over to both being files and just need to make sure how that affects a shift in workflow.
    – btmash
    Commented Sep 19, 2013 at 22:23
  • Note that features really doesn't have the concept of active and datastore/staging. Or at least not consistent, it all depends on the specific hook/thing it' integrating with. Default views live in code, for example, changes are immediately active (apart from caching), there is no controlled deployment process with features. That always has been one of the major problems when using features for deployments.
    – Berdir
    Commented Sep 20, 2013 at 5:54
  • You're right. I don't know how I got the configuration module for D7 mixed up with Features but I did.
    – btmash
    Commented Sep 21, 2013 at 15:27

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.