Where do you store your builds?

Question

We currently use Team Foundation Server to do our builds. I know we can tell TFS to keep our builds for a certain amount of time or keep them indefinitely. What if we want to keep some or all of our builds indefinitely in case we need to go back to them for some reason? Do any of you use source control to store your builds or use some type of file server to keep your builds on a file server for future retrieval? Storing the builds within the Team Build directory would cause that directory to get very messy quickly.

Of course we can always branch out an old changeset and create a build definition for that branch, but that's more time consuming than retrieving a build from source control or from a file server.

Maybe what we're trying to do is just a bad idea.

Answer 1

I'd say what you are doing is a bad idea as you suspect.

You should ideally be capable of building your complete package automatically. At that point there is no need to keep builds around. If you need what you released last month, build it automatically from the tag in source control.

If that's not good enough, then your build process isn't properly automated, and that is the problem that really needs fixing.

Answer 2

Definitely agree that builds should be repeatable. But sometimes you do need to show the exact results for whatever reason.

We use TeamCity here, and it has a feature called "pinning" -- basically we can pin any given build which will mean it is kept forever. We do this for all releases, but the 1000 or so builds that got us there are not pinned.

No idea if TFS has a similar feature.

Answer 3

The last place I was at, we burned each build to a CD. The CD had the executables, the installer, and all the source code that produced that build. This was for internal builds, obviously, we had a completely different procedure for the CDs we shipped product out on (e.g. obviously without the source code). Wrote the build number on the CD in marker, and kept a spindle of old builds next to the build machine. Low-tech and old-school, but low overhead and effective.

Answer 4

I assume you're dealing with a desktop or client-hosted application - it's unusual for a self-hosted web app to care about previous versions.

When we were working on products where multiple releases would, potentially, be in the wild at any point in time, we found it very useful to have separate branches in our version control (git) for each release, with the results of a full build checked into each branch.

The benefits were multiple-fold:

• Existing old builds were incredibly useful for support and maintenance crews, when trying to fix problems at the client, or reproduce them in house.
• A full build typically would take several hours, and require dedicated machines. Once we released a version, it was safe to say we'd want it again, and the tradeoff in space vs. time is a no-brainer.
• Convincing a client to install a patch is usually easier than convincing them to do a major version upgrade. As more and more old versions of the software are kicking around, it's advantageous to have branches you can check specific fixes into, to keep the old versions working for long enough (so clients can have time to safely upgrade to new major versions)