Every Tuesday we release a new version of MailPoet, our email plugin for WordPress. Our team of 7 developers, a quality assurance person, and a product manager has been committed to this frequency since 2016.
Some users may wonder why we release so often, and if it’s related to our team fixing bugs all the time. This is a legitimate impression that might transpire from reading our change log.
The short answer: we do fix things regularly, but it’s not the main reason why we release every week.
We stick to this weekly release schedule regardless of what needs to be released, whether we’re introducing new features, improvements, or bugs we need to fix. We’re pretty strict with our punctuality: we only missed 3 weeks last year.
In fact, if our plugin updates were happening seamlessly as part of the background process involved in maintaining a WordPress website, we would be releasing our plugin updates daily rather than weekly, just like many mobile apps or even Chrome does for desktop.
Releasing software early and often is called Continuous Delivery. I’ll explain this software development philosophy below together with its benefits for both engineers and end users in the context of WordPress.
But first, which app, plugin or game has adopted the promise of Continuous Delivery?
Apps and plugins that release (very) often
For example, the following software is released every week, or every other week:
- Firefox
- Fortnite
- Yoast SEO
- Elementor
- Jetpack
Other software developers may have a different approach and release only when they have something big to show the world. This slows down the frequency to once a month, or even quarterly. Take these plugins, for example, which are released every month or so:
- WooCommerce
- Ninja Forms
- Advanced Custom Fields
What is Continuous Delivery?
An engineering team that adopts Continuous Delivery (CD) is always ready to deploy a working version of their software quickly and safely. If something goes wrong, the engineers easily deploy a fix, or even rollback, just like you would undo a typo error in a text editor.
The objective of CD is to make releases predictable, routine jobs that can be done on demand. Deploying software is the most stressful part of any engineer’s work (e.g. “Will the app break when customers use it?”) and CD attempts to relieve some of this stress.
To achieve this state of readiness, the engineering team’s processes are clear and releasing is frictionless — as easy as pressing a button.
“To achieve continuous delivery you need a close, collaborative working relationship between everyone.” – Martin Fowler, software development author
What are the prerequisites for CD?
- A strong collaborative culture in the team; and
- Continuous automated testing, as opposed to testing the software after the developers declare it to be ready.
Adopting Continuous Delivery involves a cultural change within the team, requires many painstaking prerequisites before working, and involves a lot of fine tuning of processes. There are many tools to help engineers achieve this, but very few to measure your performance. We use a tool called Velocity, which provides some interesting team metrics.
In this insightful conference talk, which inspired us, Steve Smith, a CD consultant, argues the benefits of the philosophy through his own experience working for a large customer (a government).
What benefits does Continuous Delivery offer?
There are many proven benefits to this method. Here are the ones we feel are the most important to us.
Team happiness. Developers prefer to spend their time creating and improving features and minimize their time on menial tasks related to delivering their product. Collectively obsessing about removing friction drives team values and a collaborative culture. This is arguably the most important benefit.
Better quality. Frequent releases means smaller changes, which are easier to troubleshoot. The more frequent your releases, the less lines of codes have changed, the faster it is for a human to review.
Faster bug solving. This is specifically true for WordPress. The time to resolve a bug is shortened drastically because the team can deploy quickly.
Cheaper development. Significantly less time is spent delivering the software and debugging it.
Faster time to market. Instead of spending weeks or months building a complete feature, the team can release a smaller but important portion of the feature that users can start using and benefit from much sooner, i.g. a minimum viable product.
Iterative product design. Small iterations can be applied to product development.The benefit will be to gather early feedback to orient the product development and depend less on assumptions of what you may think the users want.
Why Continuous Delivery is well-suited to WordPress
WordPress is a brittle environment for software developers. I’d go as far to say it’s a minefield.
A plugin might need to work in at least 6 different versions of WordPress. But there’s more: web hosts have dozens of tools and services to run websites, like PHP, and each of them have different versions. The combination of all these give an infinite number of environments that plugins must operate in.
The pain and frustration of this cannot be understated for a development team because it slows product development. At MailPoet, we grossly estimate that a quarter of our engineering time is dedicated to adapting our product to all these environments.
For comparison, software as a service apps like Mailchimp or Gmail run entirely on their own servers and don’t need to adapt to unknown server configurations.
Then, there’s the potential for conflicts between plugins that add functionality to a particular WordPress site.
“The power of WordPress is its simplicity and extensibility, allowing the user to do almost anything. But that also brings a lot of complexity, as many different plugins interact together, inevitably conflicting, everyone’s setup is slightly different.” – Tautvidas Sipavičius, Chief Technology Officer at MailPoet.
This explains that releases of large plugins or themes are often followed by another just to fix bugs a few days later. Take a look at these change logs for examples:
The support lead at WP Rocket sums up how they run all their releases in this humorous tweet:
https://platform.twitter.com/widgets.js2.0 = This is a major version. Lots of shit might break! 😀
— Lucy Beer (@webtw) July 29, 2019
2.1 = We told you shit might break, but we’re fixing it, yay us!😁
2.1.1 = We found a few little things to fix, nothing too fancy though.😎
2.1.1.1 = Oops, we fucked something up but we’re fixing it right quick 😅
Plugin and theme authors depend on their users to report issues because they often don’t have the means to ensure quality before they release.
Plugin authors could rely on beta testers before releasing a final version to the wider public. But that would not work either because it would require thousands of users to replicate all environments, plus a long testing phase to allow users to report issues. The only project in WordPress that runs a successful beta phase is WordPress itself.
A weekly release schedule is ideal under the above circumstances typical of WordPress because:
- The software team fixes issues fast
- Users see resolution to their issues being solved in time
- Each release has less chance to break so many websites
In essence, your users are all beta testers. But it only works if you’re actively listening to them and fixing their issues promptly.
Update fatigue by WordPress users
WordPress consultants that manage dozens or more websites or even single site owners can find it annoying to systematically update plugins. We agree that this is annoying.
Thankfully, you can manage automatic updates thanks to plugins. All plugins in the top 100 almost never crash websites on updates, so you can consider yourself safe.
For WordPress consultants, plugins and theme updates can be managed through a centralized dashboard. WordPress.com allows you to do this via JetPack for your self hosted websites. ManageWP is a good paid alternative.
Summary
Continuous Delivery (CD) ensures that we’re always ready to release software quickly and safely.
This brings happiness in the team, for our users as well, we solve bugs faster, the quality of the code improves in the process, and it allows for iterative product design.
WordPress is an ideal platform to do this because it’s prone to host-specific configurations, for which we cannot test before releasing.
Did you know? MailPoet has a 4-day work week!
I understand why you practice Continuous Delivery but for me this concept is a big disadvantage.
I’m administrating about 40 customer sites with over 200 different plugins. When I started my business many years ago I had to install about 20-30 updates on all sites per week. These updates mostly contained a lot of changes.
But in the last years, the frequency of updates being provided by plugin and theme developers has increased dramatically (and the number of changes per release has decreased). Today I have to install between 100 and 200 updates every week! Of course, I’m using a WordPress management dashboard to streamline the update process and I set up a plugin on many sites to run a lot of plugin updates automatically. But the problem is (in the past and still today), that I can’t install all plugin updates without checking the change logs and testing the the new releases on local test sites. A lot of plugins are relevant for the proper presentation of the websites frontend and I can’t just install them without testing. As a consequence, I have to invest a lot more time today in testing and installing updates. And believe me: it’s not a funny job. It’s boring and I would rather invest my time in building new stuff for my customers.
I am very grateful that all the developers regularly update their software. But I would prefer that they wouldn’t release a new version for every little code change, apart from security fixes.
Matthias, thanks for sharing your pain.
In fact, your concern is everyone’s: plugins and themes updates might break your website. With security, this might be the biggest handicap for WordPress users.
But I think the solution to this problem lies elsewhere than reducing software updates.
WordPress as a whole has come a long ways for quality, but it’s definitely a work in progress.
Here are the things that have improved recently:
What is WordPress doing to help solve crashing website?
– they added fatal error protection
– a new troubleshooting mode to solve plugin problems
– Health check status
– minimum PHP version is increasing
– auto updates of core
What are hosts doing about it?
– updating PHP version
– offering staging servers
– including backups by default
– competition has improved the offer considerably
What are plugin authors doing about it?
– larger plugins are faster to solve bugs
– include quality in their development process
What are site owners doing about it?
– they’re choosing better hosts
– they’re selecting quality plugins
– they’re paying for quality plugins and themes which sustains development and quality
On a final note, we’re considering auto updates by default for our own plugin. This would solve a lot of issues for our support team!