The Development, Staging, and Production Model

A major source of frustration for me has always been what I call the development, staging, and production (DSP) model. This model is essential for providing the checks and balances necessary for running a high-availability production server environment efficiently. I realize as I write this commentary that I'm probably opening a huge can of worms, but I've always been mystified about why it's such an arduous task to get everyone to agree upon and establish a good model.

The basic concept of DSP servers is simple. Developers test their code on a server designated as development to see whether that application will run with other code. Simply put, that server is a development box. Once the developer is satisfied that the application is ready for prime time, the application moves to a staging server. The staging server is a mirror copy of the production server; its primary purpose is to test the completed application on the mirrored copy of production to ensure that the application doesn't break the existing production server applications. No actual code development should ever take place on a staging server—only minor tweaking of OS parameters or application settings.

The staging server is the last step before the application is ready for deployment to a production server. In many environments, a final approval process follows staging to make sure that all interested parties sign off before the application goes into production. When the application has approval, it moves to production. If the move is successful, the application becomes part of the production server.

Several commercial products can help manage a lot of this functionality. A few examples include Vignette's StoryServer, BroadVision's One-to-One products, and Marimba's Castanet. You can also use Microsoft FrontPage combined with Content Replication System, which is included with Microsoft Site Server. All of these products have complex content-control and approval processes: The real fun starts when folks argue over who should have control over which content and which server. Without such a structured process, shops that manage content manually or have a lot of diverse content have an even greater challenge.

A fine line divides who should have approval authority and who should have oversight in the process. At a minimum, the server-support teams should have approval authority over anything before it goes live. They need to have veto power over content before it goes into production. After all, the server-support teams are primarily responsible for the production server's uptime. The marketing and public relations departments should also have approval opportunities because these departments are on the line for the company's image.

These two groups' approvals seem to be acceptable without much argument. Beyond that, everything else is up for discussion. Because the server-support team has to ensure that staging is a mirror of production, should the server team prevent developers from dropping code on a staging server? Who gets that authority? To what degree should staging mirror production? Are developers inhibited by having to go through the server-support teams each time they make a change? What if the change is mere text?

These questions come up often. A company recently asked me to put together a business flow model that diagrammed the DSP process; the result would provide a generic backbone with which to compare content-management solutions. The first draft was easy—moving forward wasn't. It was difficult to agree on who should be able to do what. Lines of authority were moved, approval processes were altered, and even the definitions of each stage were reconsidered.

Finger pointing is the best evidence of not having a good DSP model. Server-support staffs chronically blame developers for deploying faulty code. Server-support staffs often have to run servers in poor health. When something doesn't work, the other party is the first to receive blame. I remember one developer who managed to deploy her own code on a production server, then blamed the OS for weeks. After almost daily phone calls to my team, she eventually found and fixed the erroneous code and actually apologized. My team quickly closed the security hole so she couldn't bypass that staging server again.

I invite discussion and feedback on this topic. Let me know how you do things differently. Drop me a line or visit the BackOffice Forum on the Windows 2000 Magazine Web site.