Plugins, Composer and Automatic Update Best Practices?

I’m re-building my deployment tooling for WordPress and trying to optimize and simplify as much of the stack as I can. Bedrock has been a great foundation stepping stone that I’ve built out from thus far. I now have 3 ansible playbooks to automate building my deployment server + WP site servers:

Ansible playbook (BuildDeploy) to build a deployment / code repo server with:

  • Git + Gitolite over SSH with authentication via keys (for deployments)
  • Git + Gitolite over “smart-http” (Apache) HTTPS with authentication via LDAP for checkin/out
  • Satis for dependency mgmt. via composer over HTTP via nginx

I keep a private repo of every plugin / version used across all the sites managed – private plugins, paid plugins as well as ones that are sourced from wpackagist or wp.org.
·
Ansible playbook (BuildStack) to stand-up a WP server capable of hosting multiple domains

  • Nginx
  • Php-fpm
  • Mysql
  • WordPress - Mix of Bedrock and the Ansible Example for WP
  • CentOS / RHEL
    ·
    Ansible playbook (DeployWP) to deploy a code release version of site (replacing Capistrano)

The last big steaming pile of legacy non-intuitiveness I have that “proper VCS process monkeys should avert their eyes” from which I’d like to improve (so please don’t avert your eyes too far away) is how I can / can’t use WP/Bedrock/composer to update plugins.

Currently:

  1. Staging / Prod have auto-updates de-activated, local dev has it
    activate.
  2. When I update a plugin via the dashboard it deletes my .git dir and
    composer.json file.
  3. Dev Site Plugin = D:\dev\sites\example.com\web\app\plugins\akismet\ It now has latest version but no git history.
  4. Local Repo Plugin = D:\dev\repos\akismet\ has previous version with full git history.
  5. Copy all files from Dev Site Plugin folder to replace Local Repo Plugin version.
  6. In Local Repo Plugin folder: git add, commit, tag x.y.z and push --tags
  7. Run satis build to update versions available for composer
  8. Go back to Dev Site composer.json file and update to latest tagged plugin version.
  9. Delete all Dev Site Plugin folders which were updated by automatic update.
  10. Composer update
  11. Re-test local dev and if all good commit the site to its’ own code repo.
  12. Deploy to stg or prod as warranted.

I bet you’re tired just reading all that. I read and tried a few things with git stash early on but didn’t have any success. I can see a few ways now that I’m more familiar with Ansible that a playbook could automate the process, but it still seems way complicated.

Suggestions?

First off, awesome job with this setup. I’m impressed with anyone running their Satis setup.

About your workflow question, I’m mostly wondering why you update the plugin from within WP? That step alone seems like it causes a lot of extra work after it.

Why not just update Satis nightly? Then your steps basically start at #7 and exclude #9 as well.

Firewall limitations during deployment phase are the main reason that I’m internally hosting all plugins composer would sync to. For local dev, the admin interface was a nice common point where paid plugins, WP.org free and private developed ones all came together but it no longer seems to be more efficient.

I looked into having separate git remotes (pull from wp.org and push to private repos) but since WP hasn’t bridged off SVN it’s either not possible or I’d end up with a lot of extraneous cruft in plugin folders trying to maintain version syncronicity.

The alternative that I move forward with for time being is:

  1. Paid or WP.org plugin? Download .zip and Overwrite local repo files.
  2. Private dev plugin?? Code, code, Iterate
  3. Plugin - git commit and push --tags
  4. Update satis
  5. Local dev - composer update and test
  6. Site git commit and push
  7. Deploy to stg / prod

One small better piece to the puzzle is that I can now add a git hook for commit a tagged version of a plugin to eliminate step #7 (in the original) or #3 in revised flow.