Do hosts and group_vars need to match?

[developdaly]

1. I'm a little confused by the hosts/ and group_vars/ configurations. My initial thought was that I could have a setup for multiple sites and multiple environments like this:

group_vars/
- example.com
- otherexample.com
hosts/
- production
- staging

And then deploy either site to either environment with all of these commands:

./deploy.sh staging example.com
./deploy.sh staging otherexample.com
./deploy.sh production example.com
./deploy.sh production otherexample.com

But those commands don't seem to work; they fail with:

fatal: [123.456.78.9] => One or more undefined variables: 'wordpress_sites' is undefined

So do the hosts/ and group_vars/ have to match?

2. In the group_vars configuration, can multiple sites be defined under wordpress_sites?

[swalkinshaw]

1. I suggest reading through http://docs.ansible.com/intro_inventory.html
2. Yes that's how it's designed. wordpress_sites is an dictionary and you can define more than one.

[JacobDorman]

I've been running into this too... needing to set variables for the deploy role per site (for example a different theme name in project_local_files).

I can add things to the wordpress_sites dictionary... but is there any reason we couldn't have a structure like @developdaly expected?

Looking at http://docs.ansible.com/ansible/intro_inventory.html#splitting-out-host-and-group-specific-data it seems the structure could be:

group_vars/
- example.com
- otherexample.com
host_vars/
- production
- staging
hosts/
- production
- staging

[JacobDorman]

I've been running into this with variables for deploy role per site. (eg, theme directory for project_local_files and project_pre_build_commands_local).

If I'm understanding http://docs.ansible.com/ansible/intro_inventory.html#splitting-out-host-and-group-specific-data correctly, couldn't we have something like:

group_vars/
- example.com
- otherexample.com
host_vars/
- development
- production
- staging
hosts/
- development
- production
- staging

[fullyint]

somewhat related discussion of splitting variables files in #133

@JacobDorman I realize you've already worked out a theme variable per site, but here's one approach to compare: https://discourse.roots.io/t/modified-deploy-sh-to-accept-a-third-argument-ansible-fails/4127/3

[JacobDorman]

Thanks @fullyint, that's actually the method I ended up going with. There's still some overlap between sites-install and deploy roles (dev/staging) but it's working fairly well.

#113 & #308 look great.

[fullyint]

@JacobDorman I was thinking about this thread here while replying to this other thread about varying build commands per site (on deploy): https://discourse.roots.io/t/how-can-selectively-run-build-commands-per-site/4557

You said:

There's still some overlap between sites-install and deploy roles (dev/staging)

Don't hesitate to point out some specifics if you think fixes would be of general use for Trellis. Thanks!

[JacobDorman]

Yep, that's closer to what I ended up with. Default/Common config for post_build_commands in deploy role default vars, merged with project_post_build_commands from sites (wordpress_sites) dict.

I've been playing around with adapting trellis for other platforms, mainly magento, which has been a good learning experience. Some overlaps between sites_install (dev) and deploy (staging/prod) are currently:

• shared folders / project_shared_children
• Create .env file / Copy project templates
• no custom commands to run after install in sites_install

Dev on vagrant with synced folders is obviously a different situation than a deploy, but might be possible to share more than currently.

That ansible vault branch looks good btw, would like to see that included.

[fullyint]

I've had a similar seed of a thought about whether there would be merit in trying to combine the dev.yml and server.yml playbooks so dev could share a little more with staging/production.

Testing Deploys on Dev VM Might be Nice
Without having developed my thoughts much, I see one main benefit being to somehow test deploys on local dev, vs. requiring a staging server to test deploys, or just deploying with hope to production, being ready to rollback. But as you mentioned, the resulting multiple releases subdirectories on dev would be probably not be synced with the VM's host machine. That's fine for testing a deploy, but we'd need a command to reset the current directory back to the synced folders so that when the developer edits code, those edits show up immediately in the dev environment/browser etc., vs. requiring a new deploy.

I first thought about all this when btamm said this

would it make sense to build out the deploy ability for development environment in Trellis to mirror the same processes for users (so the deploy process is the same across environments?) I realize it isn't technically a 'deploy,' but maybe the development deploy just runs the composer part of the deploy process?

Conflicting Purposes between Dev and Staging/Production
One reason not to merge dev.yml and server.yml are that some roles are unique to dev.yml (e.g., php5-xdebug role), but I guess that could be handled with a conditional. But maybe the bigger drawback is the difference that the purpose of the dev environment may be to show the results of edits in real-time, as the the developer works, whereas the purpose of staging and production is to show stable snapshots (releases) of the code. The first corresponds to the synced folders on dev and the latter corresponds to deploy releases on staging/production. Maybe those separate purposes justify separate playbooks/roles.

These conflicting purposes may to apply to your third bullet "no custom commands to run after install in sites_install". On dev, you might be running and re-running some such commands constantly (e.g., gulp commands), whereas on a deploy to staging/production, you'd want to run the command only once to produce a static release.

I didn't try to articulate that very carefully, sorry. If you see a strong argument for creating more overlap between dev and staging/production and want to articulate it in a new issue, I imagine people would be interested in your thoughts.

[evanfuture]

Just a quick thought, but shouldn't the "snapshot" role be left to the git branch that's being deployed? Using the git-flow method, at least, your master branch is always meant to be working and stable, and your development branch is for working off of with live changes. So, if the environments were as identical as possible, it would still leave room to develop without damaging production flow... I'm not articulating very well either...

[JacobDorman]

I think you've covered the benefits and challenges well. I hadn't thought about the releases directory on dev.

Instead of combining server.yml & dev.yml playbooks, maybe we should look at wordpress-install and deploy roles instead?

I'll have another look next time i'm at that end of a project and report back if I come up with something useful.