We recently re-launched our EDD Bookings plugin with a completely revamped code-base. The modularity applied to the development of this plugin goes beyond any project we undertook in the past, and way beyond what 99% of plugins out there have done too.
Development wasn’t the only area we worked on improving though. One other facet of our processes that we wanted to work on was the release cycle. That’s where a discussion between myself as the product owner and the developers took place.
Although you read about plenty of bi-weekly or other pre-set times for release cycles, we opted against this approach. The main reason is that every release is different, and to release on a fixed schedule is to treat them equally. While at one time we may want to focus on a few minor bug fixes, at other times we’d want to tackle some of the more demanding tasks which can easily go through multiple release periods, before then being incorporated into a release themselves.
If we were to stick to a fixed release schedule, we’d be taking our focus away from those tasks to prepare the next release, ultimately increasing the amount of time that it takes to finish said tasks. This could potentially increase the chance of human error in the process. This is known as context switching, and it’s something we want to avoid as much as possible by discussing and planning each release’s tasks and estimated time-frame as we go. By not promising shorter release periods, we hope to decrease the amount of time it takes to deliver our solutions.
How we chose what days we release updates on
We also discussed what days we want to release updates on. It was made clear that no updates would ever be released on Fridays unless absolutely necessary. For example, if there was a fatal error occurring due to a bug in our plugin, we would make an exception and release on a Friday. The reason for this is that support won’t be available over the weekend, so if something goes wrong, there would be no one around to assist the customers.
Thursdays are treated very similarly to Fridays. The only difference is that we would allow a slightly less severe bug-fix to be released on this day since we had at least 24 hours before our support team would be off for the weekend.
Mondays, Tuesdays and Wednesdays are our designated release days. Of course, an update is only released on a Monday if it was thoroughly tested the week before, both using automated and manual testing. If not, it would be tested on Monday and released on Tuesday or Wednesday, depending on how long the testing might take.
This approach ensures that we are able to release updates as often as possible without sacrificing our level of support or our sanity as human beings. In the first few weeks since the relaunch this appears to be working well. I’ll update the post if we find that changes needed to be made.
Now, ideally, we would be able to provide support over the weekend also. As you may know, small teams like ours that build, support and sell WordPress plugins (and theme sellers too) don’t always afford to do this. There are always limitations of man-hours, finances and resources which must be taken into consideration.
What are your thoughts on this approach? Do you work in a different way with your product?
0 comments:
Post a Comment