It is ridiculously fast & easy when working without “the safety net” of code repositories, composer, etc to update plugins and WP. Either automatic updates just happen or checking the bulk action update button for any plugins that acquire it. But the benefits that bedrock-type structured process provides are worth “some” process inconvenience in contrast.
I’m wondering how close to that simplicity / speed of update people have come in setting up their deployment processes with Composer and Capistrano?
My process to update a plugin version for a site for discussion context:
- Ensure I have a project setup with existing git clone of latest version
- Delete all files within the plugin folder that are not .project or composer.json
- Download updated version from source and unzip into git path
- git commit
- git push
- git tag [version]
- git push --tags
- Run satis build script to generate latest repository status
- Update composer.json in site project repo
- ssh into VM and run composer update
- If all successful check in site project changes
- cap production deploy
- re-test
Caveats / Challenges:
-
Using a satis repository for all plugins for process consistency and to maintain a single source regardless of wp.org plugins, non-published client specific or paid plugins.
-
Currently using Aptana for IDE which I’ve yet to find a way to do the version tag and commit / push as a single step. PHPStorm does look very appealing to me. Would be curious how the IDE specifically has helped anyones’ dev process.
-
If I use the update button within my local dev environment for wp.org repo plugins it deletes the .git folder of previous composer updates. Subsequent ones indicate it is missing and will not finish successfully.
-
Any other sites requiring plugin version updates are then just a composer.json file update, composer update (test) and cap deploy which is pretty manageable.
Thx,
J
