again it’s probably just me but i still have a hard time getting my head around everything - most probably i just haven’t find the right docs yet.
I’ve managed to geht the example project running, the local dev environment up and the deploy to the production server (don’t need staging for first tests).
I’m still a bit thrilled about how things are thought to be working from here?
As far as i read plugins are not intended to be installed in any other way then via the composer.json file (and the require-section there), right? So far so good. So i guess these sync with the production server via pushing it to the git repo where it is then fetched and executed with the ansible-playbook command?
What processes are handled by ansible and what is done via the deploy script that was used in the installation process? How are we supposed to do WordPress updates? I did a local update with ‘vagrant ssh’ and ‘wp core update’ (by blind guess as i don’t have any wp-cli experience so far) but a git push and running the ansible-playbook afterwards didn’t help - should this be done by the deploy script i guess?
My questions might sound terribly dumb and probably i’ve just overlooked something. If so please just point me to where i should have read and shout bad words at me…
If you update your dev VM’s plugins or WP core manually via wp-cli or WP admin, you’d have to repeat that manual process on staging and/or production. Instead, enter plugin and WP version numbers in your composer.json (bedrock composer docs). Then run composer update on your local machine (doesn’t have to be run from inside vm). This will install everything for you. That handles your local vm.
For your remote staging and production, commit your composer.json and composer.lock to your repo (don’t commit the actual plugin files). The trellis deploy will clone your project and it will run composer install. Now your remotes have up-to-date plugins and WP core.
To update plugins or WP in the future, add latest version numbers to composer.json and run composer update on your local machine, test that versions didn’t break your site, commit the composer.json and composer.lock to your repo, and run trellis’ deploy.yml. Now your remote site is up-to-date again.
Without composer, if you or a colleague takes a new clone of your project, or if your server dies and restoring from backups might mean out-of-date versions, a lot of manual updating would be required. In contrast, with correct version numbers in composer.json, you just run composer install and you’re done.
Feel free to ask something more specific, but generally, you could look through the roles/<role_name>/tasks of each role listed in server.yml to see all the steps taking in provisioning your server. That’s the setup for your server generally, with a few preparations for your site(s).
The remaining specifics of your site are set up via the deploy.yml playbook. It is simpler, with a single role whose tasks can be reviewed at roles/deploy/tasks. Most trellis tasks have an adequately descriptive name, and Ansible commands are pretty readable, so dive in to the code and you can know everything.
