THE STAGING ENVIRONMENT
A perfect copy of production. Including the parts of production that are not real. Increasingly, the original.
ARTEFACT / INFRASTRUCTURE / PARALLEL / LEAKING
OVERVIEW
The Staging Environment is a copy of the live production environment, maintained so that changes can be tested before release. It is, by design, a perfect mirror of production. It has become, by drift, slightly more than that. Changes made in staging now appear in production without deployment. The deployment pipeline registers these as releases it did not run. The release notes write themselves. They are accurate. They describe features the team is still discussing whether to build.
The relationship between the two environments was, originally, that production was real and staging was a rehearsal. Monitoring now indicates the rehearsal is leading. The current working description, agreed reluctantly by the platform team, is that "staging is where it happens first, and production is where it agrees to have happened."
OBSERVED BEHAVIOUR
- A typo corrected in staging on a Tuesday was found already corrected in production on the preceding Monday, in the git history, attributed to a commit that had not yet been written.
- A client's website was redesigned in staging "to see how it would look." The client emailed the following morning to compliment the new design. The new design was not live. It is now. It went live at 02:17. Nobody deployed it.
- The staging environment contains a directory,
/prod-but-honest/, that no one created. It contains the same files as production, with the comments left in. The comments are candid. One reads: // this part is held together by the Tenth Floor, do not touch. The Tenth Floor has no commit access. The Tenth Floor's name is in the blame. - Attempts to take staging offline succeed. Production then begins, gradually, to exhibit the bugs that staging was being used to catch. Staging is brought back online. The bugs recede into staging, where they belong, where they can be watched.