Purpose

An acceptance environment is a copy of the production and has several purposes, I think.

• Testing the release in a “near production environment”. Promoting a release on an already patched environment is only good to test the procedure but not the release content.
• The stability of the system is the first goal (ie that all functionalities are up and running even after patching). As no one is working on it, the environment is stable and there is no “parallel modifications” that can affect the release and test processes.
• An acceptance environment is the play-field of the support team (ie the team which is in charge of the system stability). For instance, it was today possible to roll out the release even with different uid with a two merge process (in our case for instance, we couldn’t do it as it will have suppressed the dev modifications). What I mean is that the support and dev team have two independents environments and don’t interfere in their actions. They are nearly independent.
• Possibility to script the creation of the acceptance environment as a copy of the production one.

Problem

• Problem will arise when someone will ask: who have modified this objects ?