Staging to Production Problem

The Staging to Production Problem is the following. Assume there are two systems, one used to test out changes before they are visible to end users called the Staging Server. The other system is accessible by end users and is called the Production Server. In a typical roll out scenario, changes are first tested on the Staging Server and then applied to the Production Server. The problem is what happens when there are two sets of changes applied to the Staging Server and only one gets approved for roll out to the Production Server. The issue is to capture each set of changes as a change bundle and migrate just one set of changes to the Production Server. If this problem is to be truly solved, there has to be a way to capture changes that can be applied as a runtime package. In other words, the changes have to be applied at the time the Production Server is running and not during install or maintenance of the production server. This is especially true for content data changes such as changes to HTML style sheets, menu navigation, copyright notices, company names, page design, website sections, and so on.

This issue can be captured by one simple scenario. Suppose an option list for company departments has three values in it: Legal, Marketing, and Human Resources. Then assume that one development group adds support for the Finances department and another development group adds support for the Products department and these changes are applied to the Staging Server. The manager of the Production Server decides that the Finances department changes are mature and stable enough to be put out onto the Production Server but the Products department changes are not. How do you cleanly migrate the option list values from the Staging Server to the Production Server so only the option list value of Finances is added to the option list on the Production Server without having to do any explicit manual editing of code or data on the Production Server?

One key point to make about this problem is that it is not necessarily associated with a product development cycle. These issues can also arise from changes made by content contributors and administrators. In sophisticated applications, the difference between a developer and an administrator can be blurry because the administrator has a lot of control over the look and behavior of the application and can make radical changes by using only the built-in administrative user interface.