At Gambit Nash we have been working on a service to automate WordPress plugin and theme updates for Git source controlled sites called WP Git Updater.
WP Git Updater will be available for usage before the end of January 2021 and we are super excited about it.
We have been using the service internally for some time alongside some beta testers to make sure it’s ready for a wider audience on launch day.
Now is probably a good time to take a look at the service it provides and how it aids our development team.
I’m going to focus on the usage in 3 of our WordPress repositories that have a variety of plugins and themes.
The Projects
Each of the projects is a WordPress site, that has between 10-25 plugins, and they all have child theme setups using different parent themes.
Additionally each project has staging and production environments, where staging is auto deployed from the develop branch in GIT when changes occur.
Each project has a number of “boilerplate” plugins we use for all our WordPress websites, namely: Jetpack, Yoast SEO, Post SMTP, and WP Git Updaters handy Display Git Status plugin.
These types of projects are the target use cases for WP Git Updater. But it’s in no way limited to them.
At its heart WP Git Updater creates branches and Pull Requests for plugin or theme updates, how you choose to organise your Git strategy or deploy changes is up to you. WP Git Updater is agnostic in that regard.
The projects were chosen specifically due to the high numbers of plugins in use on them.
It’s no secret that with WordPress websites you should aim to use as few plugins as possible, so we would categories the above stats as “high” usage projects.
The Stats
Although highly variable depending on the quantity and especially the update frequency of the plugins or themes in question. We chose the 3 projects above to try and give you a feel for the anticipated usage you may have if you used WP Git Updater.
Over a 30 day period WP Git Updater performed:
67 Total Updates
59 Plugin Updates
8 Parent Theme Updates
These updates were relatively even across the 3 projects.
This would put us in the “Professional” plan with plenty of room to spare, we could estimate from this that the plan would support 5 or more high usage projects for Gambit Nash.
In reality we have many more projects which is why the rest of this article is so important for us.
The Professional plan is priced at $50 per month, so what do the above stats mean as a cost/benefit ratio on 5 projects?
The answer as always is “it depends”. For us the breakdown isn’t just as simple as the number of updates performed:
How do we even know updates are required?
Well before WP Git Updater our update strategy was a mixture of scheduled maintenance reviews for lower activity projects, and general awareness of the team interacting with the project on a day to day basis.
This isn’t necessarily a developer, but someone in the team needs to review the project’s status.
This is especially painful as we need to allocate time to that team member to physically visit the staging sites, review any update notifications and then create tasks to be scheduled.
We have a pretty streamlined project management process using Monday.com but that’s out of the scope of this article.
Even with our streamlined approach an optimistic estimate per project just for the updates would be around 5 minutes.
How does WP Git Updater compare?
Well as we use Monday.com we can automate task creation so the cost to us is zero.
But taking Monday.com out of the equation our team members get emails when the pull request is created, from this they can action right away.
So per project the time shrinks to below 1 minute.
Time Saved
(5 min x 5) – (1 min x 5)
20 minutes per month
How much time do we need to plan updates?
Our old approach would be a conversation between the project managers and developers.
The first topic is always “where’s the changelog”, so off to google the plugin repository, search for the plugin, click the development tab and review.
Precious minutes lost with the same problem every time. I would estimate 20 seconds per plugin optimistically.
With WP Git Updater the changelog is pulled into the pull request for you, so it’s right in your email! It’s probably 5 seconds per plugin.
Knowing from experience there are a lot of common plugins/themes, so a quick review of the changelog and past experience most estimates per plugin could be agreed in a few minutes. This is no different with WP Git Updater so is left out of any comparison.
The unit of measure here is “per plugin” so let’s average that out at 12 plugins per project. Giving us 20 mins and 5 mins respectively.
Time Saved
15 minutes per month
How much time does a developer need to perform the update?
This is a difficult question to answer as every update is different.
What we can say is many updates can be signed off quickly by an experienced developer just by reviewing a diff of the changes.
To review a diff of an update without WP Git Updater you need to ensure you’re on the latest commit, run your local environment, perform the update either via the admin or cli, open the diffing tool of your choice and review.
With WP Git Updater you click the email link to see the diff in GitHub. It really is that simple.
For these types of updates the difference per plugin can be minutes (or more depending on how you run your local development environment).
For larger updates you would still likely want to perform initial testing in your local environment, but you can skip a step and save time even here. As WP Git Updater has already updated the plugin in a new branch, you can just checkout the update branch, run your environment and perform usual testing.
Between those two optimisations at Gambit Nash we would estimate on 5 projects over a month they could save us around 1-2 hours.
Time Saved
1.5 hours per month
How quickly can we get those updates to the testing team?
Without WP Git Updater the answer is monthly as per our update schedule. This is obviously sequential too.
Once we have made the updates the testing team needs to validate them before ever going to production.
Now we can react to updates more effectively, we can also provide the testing team with a steady stream of testing to perform.
Our updates are no longer just a scheduled block of work.
The time impact isn’t in the testing itself, but in building a backlog of work the testing team can complete.
While no direct time savings are made, having a steady backlog of testing requirements reduces the context shifting, waiting and communication requirements.
Time Saved
30 minutes per month
Totals
Above we have been pretty pessimistic about the time savings, there are areas hard to quantify but its clear WP Git Updater has had a positive impact on our workflows. If it wasn’t our own product I’d be much more inclined to increase those estimates.
Across just 5 projects for $50 at least 2 hours can be saved.
Most of this is developer time.
With an average developer salary of $60-$80 per hour that’s a monthly saving worth considering.
Especially when you consider this is just 5 projects. What about 10, 20, 100?
But time and savings are not why this service is important.
How often should we perform updates?
Before WP Git Updater we always aimed to do this every month for every project.
We still do monthly updates for every project now. But there is a massive difference.
On top of the monthly updates, we can now fast track many “considered safe” updates just by merging the pull requests to the staging (develop) branch.
As we run a staging and production setup for our sites, we can with good confidence simply merge updates for some of the more common plugins.
If a problem with one of these updates is found in staging, no harm no foul we can just revert and investigate.
We only do this for updates with a proven track record, honourable mentions include: Jetpack, Yoast SEO, Advanced Custom Fields, Post SMTP.
Technically there is no time saved over the usual savings referenced above, but the benefit here isn’t time.
At Gambit Nash our clients play an active role in using the staging sites, the staging area is for them as much as it is for us.
These fast track updates demonstrate our active involvement day to day with their project.
The admin areas aren’t an ever increasing update notification hell that resets once a month.
If we need to release a new production deployment outside of the usual schedule, we can also rely on updates which might not have been completed till the next maintenance schedule being present.
Simple patch release updates for security issues with plugins or themes can be notified, merged, tested and deployed within a day.
These benefits outweigh any time saving or process optimisations.
Top comments (0)