Generally speaking, we development teams will tend to have several "environments" that we deploy changes to before going live with a particular change set. An ideal minimum is four environments including databases, web servers, and other resources that apps interact with. Some resources might not be completely isolated if it adds no value.
First, we deploy to a pseudo-environment - local. Local is for integration testing our own work in isolation.
Dev is typically the first environment we deploy to. Sometimes its nightly or CI. Here we ensure that things are building once checked in and mingled with other code. We run automated tests here and perhaps have some gate process.
When its ready for testers to mash away at it, we promote to QA or TEST environment. Here is where our testers bang on the code to make sure it works and that we're delivering on our promises.
Once the release is ready to ship, we will move it to UAT/STAGE. This environment serves 2 purposes - it gives the stakeholders a place to have a look before go-live but more importantly, this is how we validate our deployment plan. We may have a number of changes that need to happen, but applied those in phases to QA. This is our chance to shake out any issues that we may encounter when deploying to a stable environment that matches prod.
Then we go live to PROD.
When something fails after we go live, we typically scramble wondering what happened. It passed QA so how does this not work in PROD!? When this has happened to me, it's often been a release that never went through that so important pre-live deployment. There are various excuses we have for skipping STAGE, all of them useless because we know better.
One excuse I've had is that we don't have a STAGE for this app. I could've used some foresight and built it. Or in the case where it would mean an extra license, I could stage in the DR environment where we do have a license.
Bottom line is that we need to deploy to STAGE so that we know we can deploy when we do go live, no more excuses.