A few clients have recently asked me to explain what I mean when I refer to staging their project, so I thought this would be a good opportunity to shed some light on what is regularly a fuzzy concept.
Staging is a private website that serves as a preview of work that has been done by developers. It is strictly for the benefit of the stakeholders on the project, and the development team.
When starting a new project, developers will begin on a development server, or in some other closed environment. Once work enters a more stable state, perhaps three quarters of the way through an initial development phase, all work will be transferred to the staging environment where the client can get a preview.
This is when your developer may tell you that "staging is the master environment", meaning that staging will eventually become the production website. Think of staging, then, as a precious seed to be nurtured, growing into your fully developed site. As with any seedling, this is the time to be extremely cautious. If, as a client, you have access to an administrative area, tread lightly! As more and more changes are deployed to the staging area from developer sandboxes, your final website takes shape.
What about a site that's already live? How does staging work in that case? Let's assume that the above linear process has happened, and the example site has been launched. Now there are two main existing environments, staging and production. Production is humming along, getting new content and minor administrative changes, but staging is now stagnant. Although it may appear to be essentially inactive, the staging environment is still valuable to the stakeholders in two ways.
- A site administrator can easily test new pages or administrative changes without the fear of accidentally ruining production.
- New work will be deployed to the staging environment.
Let's say hypothetically that a client has requested new functionality. A good developer will make a copy of the production website and, using version control software, will make code changes in a sandbox that the outside world cannot see. This work will then be staged for client review and quality assurance testing. If, over time, a significant amount of user edits and changes have been made to the database on the production site, a complete "refresh" of the staging database and its copies of user uploaded files may be warranted. A developer will overwrite the now stale data on staging with a fresh copy of these assets from the production website, and then apply his changes on top of this duplicate of production.
Now the client can see the changes exactly as they would appear on the live website (if the changes were to be launched right away), and quality assurance checks can be done against this proposed set of changes. If the changes are approved for deployment to the live site, a developer will then pull the new code into production. The developer may also have to apply one-time updates to the production database in order to complete the deployment. What may have taken months to develop will be applied to the production environment in seconds or minutes.
This is a very basic example of how a development firm might use staging, presented as a basic outline of how we use it at CommonPlaces. However, as with all web development, it can get infinitely more complicated as a site grows in complexity.
What do you think? Was this helpful? Do you have a better way? Let us know what you think.