Adjustments to config management on all b.org sites

There are three approaches to working with configuration management in Backdrop:

1. Figure 8
2. Extra directory
3. Versioned staging

Backdrop's sites all use the Versioned Staging approach, as detailed, for example, here: https://github.com/backdrop-ops/backdropcms.org/blob/master/config/README.md

I agree that this approach, out of the three above, is the best option. However, I also believe it could use some tweaking to make it better. Here're the changes I'm proposing and their reasons/benefits:

• Rename the live-active directory to active.
  • Since only two directories are needed for this approach, unlike the Extra Directory approach, we can name them more simply to avoid confusion (active is always active and staging is always staging). This also means that settings.php won't need to be updated between dev and live environments.
• gitignore everything in the activedirectory.
  • The very name of this approach indicates that only the staging directory is in version control, so we shouldn't be committing active config files. The reason for ignoring the files and not the whole active directory itself is that I'm hoping (this is untested) this will make it so that that cloning the repo will mean a blank active directory is present and ready to use as the active directory on development environments (e.g. users don't need to perform an additional step of creating a new directory).
• Remove any code/instructions that clear out the staging directory after importing to active.
  • I believe I saw some code somewhere that deleted the contents of staging once the import into active was complete. By removing this and leaving staging intact after import, users will get a copy of config files when cloning even though the active directory is empty.
• Make a policy that configuration changes NEVER happen on the live site.
  • When config changes happen on production, it means that someone with server access needs to go and export and commit those changes to the repo before someone cloning the repo can do any work on it. This is, at best, a bottleneck for development (requiring potential developers to find and ask an admin to do this for them) and, at worst, a barrier-to-entry for developers who find it too hard or confronting to do so (when they just want to make a simple PR but instead give up). This could open up more development opportunities for people.
• Make sure the drush config commands work properly, install drush on Backdrop's server and document that this is an option.
  • Typing drush bcex is much quicker and easier (and less error-prone) than manually copying files between directories. Leave the manual instructions in-place for those who prefer them, but make the drush command instructions the default.

I think that's it for now. I'll add more if I remember anything later that I've forgotten. Feel free to give feedback, suggest alternatives, etc., all in an effort to make contributing to Backdrop's websites simpler, easier, more robust and available to more people.

Note that although this is posted in the B.org issue queue, any changes made as a result of this discussion should be applied to the API and Forum sites/repos too.

[stpaultim]

I think that this issue is problematic, because it suggests that THE issue is how best to manage config files. This issues seems to work from an underlying assumption that "developers" (folks comfortable with and able to use git) are the only ones contributing to these sites.

I think the actual problem we're trying to solve is how to remove bottlenecks in the contributions to or maintenance of backdropcms.org properties and that there are different groups of potential contributors that have different needs/restrictions regarding the process.

In my experience, getting a local environment set up for contributing to forum.backdropCMS.org was harder and more complicated than getting set-up to contribute to backdrop core. I think that the proposed process, locks any contribution down to people able to get through that process - which involves things like getting access to a sanitized database.

On the other hand, our current process is blocking the most active developers in the community from actively contributing, because of how config is being managed. Ideally, we're looking for a solution that will accommodate both types of contributors.

Make a policy that configuration changes NEVER happen on the live site.

Besides limiting to who can contribute configuration changes, I question how realistic this policy would be without also severely limiting who can update content on these sites OR a very rigorous review of permissions to make it impossible for a content creator to change any configuration. It's not hard for someone from a site building background, who does not work with these kinds of restrictions every day, to forget what is content and what is configuration - in the realm of taxonomy and menu's, I still get confused myself sometimes.

In Gitter, I suggested one possible solution MIGHT be having a development environment on a server where contributors can 'stage' config changes through the UI and then have someone else commit it. However, this creates obvious potential bottlenecks of its own and still does not deal with the config/content confusion that can sometimes happen.

Thanks @stpaultim! I hadn't considered people contributing to these sites in a non-config management way.

To be honest, I've only ever used config management through my job in D8. For us, it's possible that the client (or a developer) can change configuration on the live site, but the only people using config management are developers who all have access to the live site so we can simply commit those changes before working.

Backdrop.org (etc.) is in a bit more of a unique situation in that it seems live changes are desired and encouraged (@jenlampton mentioned something similar in Gitter), but not all developers who want to work on it via config management have access to the server in order to commit those changes. Hence the bottleneck.

So if it's decided that changes to the live site are ok and we won't be restricting that, then I agree my point about that needs an alternative solution. I'm just not sure what that is...

Oh and for the record, I also get confused about what's config and what's content! 😄

[jenlampton]

Rename the live-active directory to active

The problem with this is that the name active will be wrong on any site other than the live site, since the live site is the only one that should use this directory for active config. Doing otherwise is a risk to our active config on live.

active is always active and staging is always staging

No, this is not correct.

Yes, staging is always staging, but active is not always active. The live site is the only site that should actively be reading and writing from the live-active directory, which is why it's named live-active.

This directory only stored in version control to help with config conflict resolution (see below for more details).

On every other copy of this site (local, dev server, etc) live-active will not be the active directory, so naming it only active would be confusing.

This also means that settings.php won't need to be updated between dev and live environments.

• TODO: We could change what's committed in settings.php to more closely match a development environment, instead of matching the live environment.

gitignore everything in the active directory

This would remove all the convenience of storing the config from the live site in version control, and make it impossible for us to compare changes between config from the live site and what's in staging anywhere but on the live server. This takes the power out of the hands of the many and puts it into the few. We need this feature for conflict resolution (see below for more details).

We do gitignore everything in the dev-active directory, which is the directory all dev sites should be using as active. This is why it is named this way, and already treated as recommended here.

I'm hoping (this is untested) this will make it so that that cloning the repo will mean a blank active directory is present and ready to use as the active directory on development environments (e.g. users don't need to perform an additional step of creating a new directory).

This problem should already be solved by the empty dev-active directory. It's named clearly, and ready to be used "as the active directory on development environments". Developers Shouldn't need to perform an additional step of creating a new directory?

• TODO: verify that an empty directory named dev-active is present in all b.org site repos.

I believe I saw some code somewhere that deleted the contents of staging once the import into active was complete

Ah, this is what Backdrop core does. It's not part of our workflow -- it's something done by Backdrop that our workflow needs to compensate for.

The directions should say to git checkout after a sync, which is the opposite of clearing out -- it's putting everything back.

• TODO: check permissions on all staging directories on backdrop servers so that Backdorp itself is not capable of deleting config files from staging.

Make a policy that configuration changes NEVER happen on the live site.

The problem with telling everyone that they are not allowed to submit any forms on the live site is that it will prevent anything from getting done. This takes the power out of the hands of the many and puts it into the few.

We have admins on all our websites who have great admin skills at building things like views and layouts and adjusting content types, but these people may not be comfortable with config workflows (or, this particular one). If we take all the quick and easy tasks that lots of people can do, and make them into hard and complicated ones that only some can do, everything will grind to a halt.

The whole point of Backdrop is making a product that empowers more people with user-interface skills to do more of the work, and rely on “developers” less.

Locking down live is a non-starter.

When config changes happen on production, it means that someone with server access needs to go and export and commit those changes to the repo before someone cloning the repo can do any work on it.

In general, its safe to assume that the config files committed to live active are "close enough" and this should never prevent new work form being done.

In my experience, changed files on live are rarely the same files I've been changing locally. Even when they are, the config sync review step makes it fairly easy to resolve-- as long as you are using the live-active and dev-active directories correctly (see below for more details).

Because we have the live-active directory, config changes from live will be committed there, and will NOT conflict with any work being done in staging and/or dev-active.

It's the job of the person deploying new changes to check live for any differences first, and if so, commit them.

If there are new changes to live config, the person making the changes to staged config can safely do a git pull to update live-active.

If the dev site showed no config changes between staging and dev-active before the pull, then afterward they can manually copy files from live-active to staging and view the config sync page to see what's changed on live. In my experience, dealing with conflicts at this step is usually as simple as committing to staging. Only once have I have needed to sync and re-do my changes (they were both changes to the same layout).

I would like to improve the experience of everyone who wants to work on b.org properties, so I added some TODO's into this comment where I think we can solve your concerns with minor changes to the current workflow.

I would also like to look into a better way to solve the live-active out-of-date problem, but one that won't prevent work from getting done.

• TODO: look into adding something that does an automatic commit on live when config files change.