I would like to get some feedback on this idea, as I can see the pros and cons of each approach. As a Java developer, this would be about storing jar files in the code repository, but it could easily extend to other compiled languages.
Pros:
Cons:
We archive releases to a directory structure, and tag the appropriate versions in source control. This gives us access to the built versions and the source that generated them.
This is easily done using build scripts to automate tagging and archiving of release builds.
Compromise: store tools and source code in repository and tag builds. This way you can always recreate any build of a product.
And you can always have a separate repository for compiled artifacts.
Put specific customer releases in the repository.
In theory this isn't necessary since we could always reproduce that version but it's nice to be able to just get the exact .msi that was sent to a certain customer on a certain date - we then test that in a clean vm.
One reason is that it protects you against any changes outside your build environment from say Windows or visual studio update. You might not be able to reproduce a bit-bit build of an msi if msi itself has updated!
I think it is appropriate to store build output in the version control system. Both for testing some specific version of a build and also in order to ease certain development tasks.
However, you should make sure that you'll also keep everything in the repository that would be needed to recreate that exact build if need be. You should use consitent tagging/labeling in order to facilitate this. You may need to test a bug fix with different versions of various components, and depending on the complexity of your overall system you might want to try different combinations.
We go for labelling the repository for any build so we can get the actual source for any build number & then we zip and upload the actual published build files that are actually deployed - just to be sure there's no sneaky last minute config tweaks etc during deployment that areb't reflected in the trunk itself.
If you can create a good enough build system that it is trivial to recreate an exact build with just a checkout of code, I don't believe there is any need to store your builds in the repository.
For most of my stuff I do not store specific builds of my code, but I do store specific versions of the libraries my code relies on. I put a lot of effort in a few months ago to make it trivial to load in a tag and type "ant" and everything builds properly without relying on anything outside of the tree. (excluding the correct javac and ant)
Unfortunately, some of our codebase does not have as good a build system (ie, requires manual setting up of sdks and grabbing various external libraries and poking environment variables) and it would be difficult to recreate exactly a specific version of a build based on the repository (we are constantly moving forward and not really supporting old code, so the developers' workstation are set up close enough that we haven't been burnt yet by having to go back to an old branch before our current release) and in that case, we do store our release's builds (for the inevitable fat finger "oh no, I was on the wrong server doing some tests" or something equally insidious).
Sometimes. Most of the time the answer is no but there are still scenarios where if it makes sense, do it.
As an aside, I'm surprised this is still open. These discussion type questions are usually voted closed in less than 5 minutes.
I don't think there is a good reason to version the actual build. Tag the source version and make it so that only a controlled group has access to changing the tags. A build tag should never have a checkin done to it so it should be trivial to recreate the build.
Hello,
I store the builds on a folder in the server, and they're backed up on a regular basis. But I tag the revision which represent that build. In the build folder I store not only the executables, binaries or pages (our case is ASP.Net), but also the change scripts we get from SQL Delta.
The tags are named with the same identifier than the fields, so if you have the build "System_2009-07-30-01" you'll have a tag with that name. So if you need to fix something, you simply look at the build name, look the tag and then look the revision you need to see what may be happening.
To mitigate the concern that old build tools may not work in newer environment, we archive our build machine images for major releases. It is easy to do for us because our build machines are virtualized. It's plan B in case other means do not work.