Join Log in
Score:0
Extect avatar Drupal

How to deal with config changes in prod and by multiple developers?

cn flag
Extect

I have two scenarios in configuration management that I am unsure how to deal with:

  1. Geeky user makes config changes in production. What is the best practice to import these changes in dev without destroying the work that is being worked on in dev? git pull and drush cim would override everything you are working on in dev. I know there is drush cim --partial, but from what I understand this is not the recommended way of doing it (Source). I could also use configuration read-only module in prod to avoid config changes at all, but there are several examples where the user should actually be allowed to change config.

  2. Two devs work in their local dev environments: How can I ensure one is not overriding the work from the other when pushed to stage or prod, particularly when there are also config changes in prod happening (see 1)? Probably some way of git branching may help, but I could use some more help on how to exactly use it.

117
2 + 0
8
Score:4
Les Lim avatar Drupal
us flag
Les Lim

Good use of git branching can definitely help with this. The key thing is that each individual branch has a stable configuration basis: nothing external to the branch should change the configuration state within the branch, so that later when it's time to export configuration in the branch and merge it into production, only the changes relevant to the branch are recorded.

One way to do this is to have a main branch called production, and the HEAD of that branch always tracks with the current production state of your codebase. You all agree not to commit or merge things to production unless you're preparing to release those things live.

When Arjun wants to work on a new feature, they make a new branch off of production, and they call it arjun-1.

The next day, Beth needs to fix a bug, so she makes her own new branch off production called beth-1.

Meanwhile, content manager Ceci is in the site UI building out webforms, which means she is making live configuration changes that diverge from the config state of production. In a way, she too is branching off of production! In fact, let's go ahead and create a ceci-1 branch off of production now to represent this, even though we probably won't commit anything to it yet.

A few days later, Arjun and Beth's respective branches have been reviewed and accepted, and management wants to deploy a new release with their work to the live site.

The first thing to do is check out the ceci-1 branch, export the live configuration and commit the updated config files to ceci-1.

Now you can proceed to merge to production: the new feature arjun-1, the bugfix beth-1, and the live configuration updates ceci-1. There may be merge conflicts to review, but you should not have to worry about accidentally overwriting someone else's config. This is because each individual branch had a consistent basis from which to export their own individual config changes.

Let's say you didn't make a ceci-1 branch. Instead, you merged arjun-1 and beth-1 into production, then exported the live config and committed the live updates into production. You have screwed up! You changed the basis for Ceci's live site configuration changes. They had been based on the state of production without Arjun and Beth's branches. Exporting now will overwrite any configuration changes they had made.

0 + 1
Extect avatar
cn flag
Extect
Thank you so much for the detailed reply!!!
0
Reply
Score:0
Jaypan avatar Drupal
de flag
Jaypan

Changes should never be made in production. Production configuration changes should be made locally by developers. Merge conflicts should be sorted on their local machine. So, it would go like this:

  1. Developer checks out code
  2. Developer makes changes exports config
  3. Developer tries to push, gets rejected to do new commits
  4. Developer pulls, sees changes in configuration
  5. Developer imports new configuration to ensure it imports properly, and that the changes in his commit are not disrupted
  6. Developer exports configuration after making any fixes, commits, and pushes to the server

Any changes to configuration made directly on remote servers should be expected to be overwritten with every push. This solves your above issues, except maybe:

there are several examples where the user should actually be allowed to change config.

Such as?

0 + 4
Les Lim avatar
us flag
Les Lim
Such as: adding or configuring webforms, rearranging blocks, adding user roles, adjusting workflows, changing image field default images, etc. Sure, it's great if this can all happen in a controlled dev environment, but most Drupal sites don't have a dev team that can shepherd all those changes through deployment workflow.
2
Reply
Extect avatar
cn flag
Extect
Thanks @Les Lim! These are exactly the use cases I mean. Some projects need more flexibility or the project is so small that there is no dev team available all the time to do changes in a controlled dev environment. In both cases there is more changes being done in prod and this is exactly the issue where I am confused what the best workflow would look like (if there is any).
0
Reply
Jaypan avatar
de flag
Jaypan
I personally have a delieation with clients that config changes such as above are site building, not content management. I don't see situations where clients should be adding user roles, changing workflows, and changing default images on fields. We build sites for clients to use, opening up site building to clients opens up problems - such as this one!
0
Reply
Jaypan avatar
de flag
Jaypan
I should add, layout builder can be used to get around the problem with blocks. Webform is the biggest issue I see for you. I don't use it though, as it only opens up problems in my experience. The exception where I'd want to use it would be where the project requirement is the client being able to build out their own forms.
1
Reply
ธงชาติไทย
Elon Musk
I sit in a Tesla and translated this thread with Ai:

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.