I’m using Perforce, if that changes the tune of the answers at all.
I’d like to implement a build process that, when a solution is built in a “release” mode, tags the entire source tree with a label and pushes the output of the build (DLLs, webpages) to a /build/release directory in source control. This directory should always contain the latest complete build, nothing less and nothing more, so I can yank that directory to production servers in its entirety and it’s ready to go.
Now say I had a DLL in a previous release that the new build is not supposed to include. Does this mean the best practice for updating that /build/release folder is to check the entire thing out, delete everything in it, add the new build files, and sync it? Sounds like an obvious answer, but I want to make sure I’m not missing some other voodoo that might be a better way to do it.
I think you are missing the simple voodoo:) You should consider just using a plain old file system for your build drops. Source control is designed to manage change, versioning, and collaboration and there really is no need for any of this related to builds. The whole point to an build system is to be able to reproduce the source code and create the application at a moments notice so I would focus on being able to do that more than relying on the permanent storage of the output files. Be sure to back up the build drop folder structure just as you would the source control database. Use a folder naming scheme that includes the build number in the filename. I would store all of the builds (back at least several) because there are times when QA wants to restore an old build to test in order to compare features or resurrect a bug. Using this system every build gets a new folder so you don’;t have to worry about deleting out old files.