DEV Community

Cover image for How to measure deployment frequency for WordPress plugin
Slava Vasenin for Visual Composer

Posted on

How to measure deployment frequency for WordPress plugin

One year ago I read a very great book about DevOps science "Accelerate".

There was a chapter about measurements that can be used to answer the question: Does your company has High-performance team in the development?

These measurements:

  • Deployment Frequency
  • Lead Time for changes
  • MTTR
  • Change Failure rate

One of the most interesting points is Deployment Frequency and we had a long discussion about this in my team about that. The book says that the high-performance team should deliver on-demand, multiple deploys per day.

The problem is that if we will publish one plugin every day multiple times in "WordPress.org" people won't like it because there are no automatic updates for Wordpress plugins in the admin dashboard.

So, Publishing so frequently isn't an option, but the concept to have a deliverable product as often as the possible sound really useful.

We use a trunk-based development branching model. What does it mean?

A source-control branching model, where developers collaborate on code in a single branch called ‘trunk’(master), resist any pressure to create other long-lived development branches by employing documented techniques. They, therefore, avoid merge hell, do not break the build, and live happily ever after.

There is a master branch were we merge all pull requests. Is it safe? From point of continues integrations, we run tests pipeline for every commit and every merge. Sound safe! How true is it? Not sure. No one during the merge of the pull request thinks it can be delivered to the customer at once.

The only thing left is to update the release brunch as frequently as possible. Here is our scenario:

  1. Developer crates pull request. Before all CI pipeline's tests have been successfully completed.
  2. A reviewer checks code and confirms this pull request as valid.
  3. A reviewer merges pull request.
  4. Release engineer checks during the day the state of the master branch and if it has updates, decides are this code safe for the update in the current release branch.

So every update counts as deployment. Makes sense, isn't it?

Conclusion

If you have any suggestions or you want to share what kind of practices you use in your company, please welcome to write comments :)

Thanks and Good Luck 🚀

Top comments (0)