Very well-written article!

The process you describe is strikingly similar to one I developed for our environment, major exception being that we use source control, and the deploy is executed from the "DBA" source control working structure- thus enforcing that all changes are in the codebase.

One benefit you didn't really emphasize is the transparency and documentation trail left behind by this process, especially if you incorporate script logging (basically Print statements recording timestamped progress) in the change scripts and/or deploy scripts. We actually invoke SqlCmd via a series of calls in a DOS batch file, passing source code files from the DBA working location. The DOS "Deploy Scripts" are named referencing a sequential Deploy#, and copied locally to the server in an "Installs\SQL" location by the Deploy Job; the "Prepared Deploy" folder, including Deploy Instructions from the Developer, as well as DBA-mediated scripts like Alter Tables etc., also named with the Deploy#, is archived. This provides a very clear documentation trail of exactly what happened and when.

Now if we could only get the Developers to follow the prescribed development methodology, to allow this process to work as well as it should...