Deploying on Time to WordPress VIP

By: Ryan Kienstra on: March 5, 2015  in: Programming

deploying-on-time iconWith the WordPress VIP code review process, deploying on time can be a challenge.

But a VIP Developer Orientation video has great advice on this.

And the VIP coding standards are just the beginning.

Commit Messages

In the orientation, VIP engineer Spencer Cameron-Morin said that detailed commit messages are crucial.

He said that they could take longer to write than the code.

Cameron-Morin used the example of a bug fix commit.

He suggested that the commit message have the entire background of the bug, with links to tickets concerning it.

Message Components

The WordPress VIP documentation lists several components of commit messages.

  • A short subject line, with a reason for the commit if it isn’t obvious.
  • A blank space, followed by a longer description.
  • The reason for the change.
  • The causes and effects of the original problem.


Different developers might contribute to a single VIP commit.

And their separate commit messages must be compiled into a single message.

It’s very important that each of their messages be clear.

The git documentation has good advice on this in its page Distributed Git.

Like in the VIP commits, it suggests a single-line description, a space, and a detailed explanation.

But it also calls for:

  • A description of how the new implementation differs from the old one.
  • Use of the present tense imperative, i.e. “Fix bug in…” instead of “I fixed bug…”

The message should be sufficient to understand the commit.

One shouldn’t have to read all of the code to understand what it does and why you changed it.

Commits: Atomic and Compact

Because of the code review process, commits shouldn’t rely on other commits.

And they must be small enough to not cause problems if they’re reverted.

Review Process

When you first submit a theme and plugins, VIP reviews them in their entirety.

Once they’re deployed, further changes are usually treated as commits.

These go to a queue to be reviewed line by line.

The reviewer will revert a commit if it has a big enough problem.

And VIP will often revert a commit if there’s a problem in production.

So each commit must be self-contained.

Modular Code

When possible, commits should use action and filter hooks to interact with other commits.

Using functions or variables defined in another commit can be dangerous if a commit is reverted.


Cameron-Morin suggested grouping related commits in changesets.

One example he used was escaping improvements.

Still, these changesets shouldn’t be big enough to cause problems if they’re reverted.

Big Commits: Use Zendesk

If you need to submit a big change, you might open a ticket in VIP’s Zendesk account and submit the SVN patch.

Cameron-Morin used the example of a theme rewrite.

This keeps it out of the review queue.

VIP can review other commits at the same time.

And if the queue is clear, CSS and image files will be auto-deployed.

Deploying On Time

VIP coding standards are important. You might read my articles on them.

But these standards should be applied in atomic commits, with clear messages.

As Spencer Cameron-Morin said, this will help you to deploy on time, and avoid problems in production.

Leave a comment