In this series, we're taking a look at the various practices that are used in professional WordPress development. In the previous article, we reviewed a set of strategies and reference material that are useful when building themes, plugins, and WordPress-based applications.

In this article, we'll take a look at version control and environmental configurations that make it easy to develop, test, and deploy our work to minimize the amount of errors that find their way into final versions of our work.

Version Control

This topic is nothing new. In fact, I'd venture to say that the majority of readers here are familiar with Subversion and/or Git (especially with the popularity of GitHub). As such, the point of this article isn't so much to give a tour of the various source control systems or to make a case for which ones you should be using but it's meant to make a case for why you should be using source control and how it's related to our environments.

If you're completely new to the concept of version control, let's provide a simple definition off of which we can work so that we're all on the same page:

Version Control is a snapshot of your source code at any period in time that allows you to rollback when a bug is introduced and work on a new feature without breaking existing code.

Within the WordPress community, people are often divided on whether or not to consider themes and/or plugins software or glorified websites. Personally, I believe they are a form of software as they are subject to many of the same practices:

• Coding Standards
• Design Patterns
• Layers of Abstraction
• Unit Testing
• API's
• ...and so on.

To that end, developing and maintaining WordPress-specific work should be treated as such and it's industry standard to provide a level of version control on software.

Additionally, version control works hand-in-hand with working on your project, testing it, and then deploying it onto a live server for others to use.

The Environments

Most developers are familiar with the various environments even if they don't use the exact terminology. Simply defined:

• Development usually refers to your local machine where you have your web server, database, IDE, and related tools installed
• Staging (or Testing) is a server the resembles where the project is actually going to live and where you upload your work for testing
• Production is where the project is live on the web with real content and where users actually interact with your work

Simple enough.

The thing is that each of these environments are also closely related to version control in such a way that when managed correctly, you can minimize the overhead of maintaining versions and deployments of your work.

Development Environment

The Development Environment is the machine on which you actually develop your project. It includes a copy of WordPress, the web server, database server, IDE, and related tools that you use to build your project.

This particular environment is where you should be doing frequent commits. By this, I mean that every time you make a significant change - be it a new feature, bug resolution, or something similar - then you should be committing code to the repository.

Here, the advantage is that you're able to easily rollback, identify, and distinguish between changes should something go wrong during the process.

Once you've completed a significant amount of changes (where you or your team determine what constitutes "significant"), then it's time to mark the set of changes and deploy to the staging environment.

Staging Environment

The Staging Environment is a separate server that resembles the Production Environment, but is used to test the project before releasing it. It includes the latest version of the code, test data, and is meant for users to evaluate the project prior to releasing it. No development should occur here.

Though no development should occur here, it's not uncommon to have various debugging tools in place in order to generate log messages or review what's going into and coming out of the database while working on the site.

Since developers often commit a set of changes to the repository, they need to be tested. This is where the Staging Environment comes into play. Generally speaking, the Staging Environment often corresponds to whatever the latest set of changes were committed to the repository.

But this raises two questions:

1. What Do We Do if Bugs Are Discovered?

First off, this is a good thing - it means that the Staging Environment has served its purpose! Additionally, it gives us a chance to review our source code to determine if a bug must be resolved or a new feature should be introduced.

And this is where source control comes in handy.

If a bug has a occurred, you may lean in the direction of rolling back the change, but in the Staging Environment that's not necessary. Instead, you simply locate where the bug is, resolve it, commit the code, and then redeploy the code to the Staging Environment for testing.

You repeat this process until no bugs exist or, more accurately, you're unable to locate any bugs.

2. What Do We Do if Testing Yields No Errors?

If you're unable to locate any bugs, then you've essentially got what's referred to as a stable build. At this point, you can tag - or stamp, or label, or whatever convention your source control system offers - a version of your code and deploy it to the Production Environment.

Of course, there is a chance that a bug can be discovered after being deployed to the Production Environment. In that case, special action should be taken.

Production Environment

The Production Environment is synonymous with the live site. This is where actual users are creating, managing, and interacting with actual data. No development should occur here.

There's very little to speak about the Production Environment as far as development is concerned. After all, this should be nothing more than where source code is deployed for others to use.

But there is a chance that a bug could be released here. When this happens, this is when a rollback should occur. Simply put, a rollback is when you take the latest set of changes and literally undo the deployment restoring the project into its previous state.

Prior to performing a rollback, it's worth noting any recreation steps so that you can reproduce it in both the Staging Environment and the Development Environment in order to properly solve the problem.

From here, perform the development that's needed to resolve the issue, commit another change, deploy it to the Staging Environment, and deploy it to the Production Environment assuming that it passes testing.

On Version Control and Environments

Obviously, this particular post covers concepts at a high-level: We're not exploring which version control systems are best nor are we looking at which tools are best for your particular operating system. These topics are outside the scope of this post and are each deserving of their own series.

However, within the concept of Professional WordPress Development, these practices can obviously prove useful in development, testing, and deploying (and rolling back) versions of your project.

In the final post, we'll take a look at some of the various tools that are available that will allow us to diagnose many errors in our local Development Environment with the intent of preventing many of them from even reaching the Staging Environment.