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.

4 Answers 4


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.


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.

  • The only caveat that I would add is that you need to keep your build chain under version control also. If you built the last release before Service Pack 1 (or whatever) was released, then building it now (after SP1 is applied) will probably not build the same thing.
    – Peter K.
    May 6, 2011 at 19:48
  • 3
    That all sounds a bit idealised to me: keeping recent development builds around for testing and reference is useful. Keeping all release builds (along with debugging symbols) must be mandatory. Who know if you can guarantee that when a customer on build X comes back and reports a crash dump from 2 years ago that your current build process will be so well tuned that it will, with no effort, build today the source code it built then.
    – user23157
    May 6, 2011 at 20:48
  • 1
    If you ship it keep it!
    – SHug
    May 6, 2011 at 20:53
  • Where do you keep your release builds? On a file store that is backed up daily?
    – Bob
    May 7, 2011 at 1:49

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.


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)

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.