When it comes to launching the final version of a product be it a theme, plugin, or a web application regardless of it’s built on WordPress or not, source code control can be a life saver.

This is why most developers live and die by the source control system that they use.

Before going any further, this isn’t a debate as to which is better – Subversion, Git, Mercurial, whatever – as long as you’re versioning and tagging the code that you’re working on, you’ve got something to rollback to using if something goes wrong with your latest build.

Imagine that you’re in the following scenario:

You’ve got a project that you’ve been working on for a few weeks or for a few months and it’s about to go live. Everything is working great.

Then, shortly after it launches, something needs to be changed. And this isn’t like a small grammatical change. Instead, this is a change that requires some major refactoring and possibly the re-architecting of a significant feature.

Sure, you hope everything goes well, but there’s far more to it than that if you want to it do it correctly.

So what is the best way to go about doing this?

Releasing New Features

In terms of the best way, I’m not sure I have an answer, but in terms of ways that you can go about doing something like this, there are a few strategies that I’ve seen used (and used myself) that I’ve found to be really helpful.

A Control Flag

Think of a control flag as a variable that’s set somewhere in the application – perhaps it’s in a script, perhaps it’s in a JSON file or an XML file, or perhaps it’s in a query string variable.

When that flag is set to true, it uses the new code rather than the old code and allows you to see how it’s performing in production. This gives you a first-hand view as to what the user is seeing and also gives you a chance to peek into the logs to see if any problems have come up.

A Staging Environment

This really shouldn’t be a point of discussion as every project should have a staging environment (at least arguably so); however, once you’ve launched an application into production, it’s a good idea to make sure that the data that’s in staging contains at least a subset of the data that’s in production.

This will ideally give you a similar idea as to what the users will experience when hitting production and will, like the control flag option mention above, allow you to see critical information via the logs.

Time of Day

Depending on the nature of your application, you may be able to get away with deploying changes at certain times of day that cause very little hiccups.

For example, if you’re working on an intranet application for a company that works 9-to-5 then maybe deploying the latest change after hours would be acceptable. If all things check out, great; otherwise, roll it back and wait until later.

This particular option is cumbersome because you have to wait a significant amount of time before checking the performance again but it is something that is done depending on the nature of the project.

Last Known Good Build

As a last line of defense, if you’re latest deployment causes a problem and you’re unable to fix it in the expected time (because, let’s be honest, we’re all bad at estimating time to resolve a problem) then simply rollback to the last known good build.

Perhaps this was the last tag that you created in your source control system. Or maybe it was the prior branch that you were running.

Whatever the case, redeploy what was last working despite the fact that it comes at the expense of a refactored feature. This means that the users are able to carry on with as little trouble as necessary and the development team – no matter how big or how small – can get back to work on the project, rinse, and repeat one (or more) of the above.

There Are More

Of course, these are just suggestions and this list is my no means comprehensive. There are plenty of other strategies that can be used in order to deploy new, working code.

It’s scary, stuff breaks, and rolling back is something that we often have to do.

But having a plan of action ahead of time is great as it alleviates a lot of stress that obviously beats the alternative. So next time you go to deploy a major change to a version of a product to production, make sure you have some time of contingency plan.

And if there’s something else that you do that isn’t covered in the suggestions above, feel free to share them in the comments. Having a collection of as many possible ways to handle this wouldn’t be a bad thing.