Abstract deploy specific changes to a user / config directory

[btopro]

Something from ELMS:LN / Grav land. Grav abstracts all changes made after deploy into the user directory. This makes it super easy to know what to upgrade, what to version control, and where all credential data is vs what's safe to give out. ELMS:LN also does something similar using symlinks where all of our deploy specific changes actually live in a config directory. In practice what happens:
https://github.com/elmsln/elmsln-config-example is git cloned and replaces config folder in elmsln high level structure
https://github.com/elmsln/elmsln/blob/master/.gitignore#L5 ensures it's ignored from VC

Deploy UX that will never cause a data loss as a result:

cd /var/www/elmsln
git fetch --all
git reset --hard origin/master

Or when new version of our codebase release
cd /var/www/elmsln && git pull origin 0.10.x will safely work on any deploy that's ever made which doesn't modify this core convention. This allows us to start automating deployment and maintenance scripts.

This will never blow away anything made after the initial stamp down of the data. It's not to say my structure is right, just that I know it helped our developer UX immensely / simplified process after the fact. Grav's user folder offers similar workflow advantages when it comes to upgrading "core" at a later date in the same regard.

[csev]

Does git reset --hard origin/master delete files that are in .gitignore? I don't think so. I agree that allowing a git reset is a valid use case.

[csev]

I honestly find the grav config / user (i.e. what to version control) leaves much to be desired when you are first starting out with the product. I do not like the notion of a folder tree where there are some folders that should be in version control, others are machine generated, and others should never be in version control and it is not at all obvious when you start using the product what does where.

I do ultimately support the idea that config should be somewhere completely "elsewhere" so you can version control a set of configs in a private repo and link them together in production. This could be done in Tsugi by writing a config.php that simply imported a file elsewhere in the hierarchy or just did a soft link.

[btopro]

git reset will respect .gitignore'd files. So if it's setup correctly you can ensure a clean slate for such things. Drupal 7 to 8 saw them shift a lot of the "what do I change" to more of a "do it all in this folder".

Alternative I forked from their structure which has worked out well --

• config - all the stuff that changes after the fact
• core - don't touch a damn thing in here ever
• docs - documentation ships
• domains - apache tree to map to; in your case could allow a place in docs to say "point apache here and your good". This also allows (in our use-case) to have the files delivering the experience actually living in structures below the web-root. This keeps things like server level scripts unable to be accidentally made web accessible even if we screwed something up
• scripts - server level scripts and utilities

This grouping's given us a nice separation of the mental model people are in. Our config.php you reference is also kept in these structures, allowing us to have more of a bootstrap.php style file which would invoke config (as opposed to now where you chain everything off config.php). This would give an additional layer of abstraction (like if someone wanted to have a system manufacture config.php's dynamically) while Tsugi would be focused on hooking all code back off of the bootstrap file.