Why We Release Every Week, or Continuous Delivery Explained

Oiling chain of bicycle

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
  • Facebook
  • 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
Tandem bike for 3 people

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.

Hands on bike handles with electronic mount.

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:

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:

  1. The software team fixes issues fast
  2. Users see resolution to their issues being solved in time
  3. 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.