Hi Dev Comm- I've been at organizations that have deployed from DEV to UAT using a single iterative Change Set -- and when all items for a particular release had passed UA/QA Testing, the Change Set was then deployed from DEV straight to Prod.

(DEV --> UAT || All Items pass UA/QA in UAT? Yes || DEV --> Prod)

However, having moved on to other companies, there seems to be different schools of thought about this practice.  I've heard from others that a Prod deployment should always originate exclusively from UAT (Staging), whereby the Inbound Change Set into UAT should be re-built as an Outbound Change Set to then go to Prod.

(DEV --> UAT || All Items pass UA/QA in UAT? Yes || UAT --> Prod)

However, it was for the very reason of Inbound Change Sets not being able to be cloned as Outbound Change Sets that my presvious company actually encouraged a Prod deployment using a clone of the "final" Change Set that was deployed from DEV to UAT -- thus, we subsequently deployed from DEV to Prod.  You see, some of our Change Sets included *hundreds* of components, and this takes precious time to have to rebuild manually, each deployment.

As a general rule, is deploying a Change Set from a DEV (pre-staging Sandbox) to Prod be discouraged for any reason -- provided that no net-new development/config has taken place in that Dev Org and that all metadata is perfectly in step with Prod?

I want to ensure that I am always following best practices and absolutely do not want to take short cuts that would be perceived as being detrimental to Change/Release Management processes.

Thanks!