Existem várias razões válidas para sair deste fluxo de trabalho típico. Nós não temos um ambiente de QA como o @CamelBlues sugere, afinal o código deve ser QA antes de ser marcado como completo e pronto para passar para o staging. Nós utilizamos o controle de qualidade em tempo de desenvolvimento e, portanto, não precisamos de um ambiente de controle de qualidade.
De qualquer maneira, grandes mudanças no código, como substituições de interface do usuário ou coisas que causam a necessidade de um ramo adicional de desenvolvimento, muitas vezes também exigem um lugar diferente para testar e realizar o estágio do que o ambiente de desenvolvimento principal.
Por exemplo, se estou substituindo minha UI e portando meu aplicativo para um novo sistema MVC, posso criar uma nova ramificação para realizar isso no repositório de controle de origem. No entanto, não posso executar meu código legado e o novo código MVC juntos, por isso precisaríamos de um novo ambiente para hospedar esse ramo até que ele seja concluído. Especialmente se você ainda tiver que consertar bugs ao longo do caminho.
Apenas lembre-se ... isto é EXATAMENTE para que servem as máquinas virtuais. Você pode até conseguir usar as licenças de avaliação de 60 a 90 da Microsoft (se for sua plataforma) para fins de desenvolvimento e teste. Realmente não importa quantos ambientes são solicitados (dentro do razoável e comparados ao tamanho da sua equipe) porque você deve ter uma plataforma para girar as máquinas de maneira fácil e rápida, é assim que as lojas virtuais maiores operam e realmente permitem que os desenvolvedores e desenvolvedores testem. -out VMs para usar.
Atualização: Acabamos de conferir nosso ambiente e também temos uma pré-produção. É usado pelo release & equipe de implantação para testar as instruções e correções para fazer uma verificação a seco antes de realmente tocar nas caixas de produção. Dá a eles um buffer.