Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

How do you keep released binaries under version control? This allows to track which stuffs are changed between each release. I mean to separate the released binaries from source repository. The released binaries are either built from Continuous Integration software or manually compiled.

share|improve this question
    
What do you mean by "track which stuff has changed"? What attributes of the release binaries are you (or want to be) tracking? It just seems odd, so I am curious. –  Jeremy Heiler Jun 7 '12 at 5:48
    
e.g. between v1.0.0 and v1.0.1, only ABC.exe is changed, while the dependency DEF.dll remains unchanged –  linquize Jun 7 '12 at 6:13
    
How do you determine this by looking at the binaries? –  Jeremy Heiler Jun 7 '12 at 6:15
    
diff old and new version of same file –  linquize Jun 7 '12 at 7:32

5 Answers 5

Two options:

a) Don't. Just make sure you have reproducable deterministic builds, that is, building the same source control revision with the same configuration always produces the exact same binary.

b) Designate a directory somewhere as the authoritative source for published builds. Make uploading the binaries part of the deployment / shipping procedure,and make sure the published-build directory is covered by your backup plan. You don't need any version control here; builds are write-once, if you need to change anything, you make a new build.

Either way, binaries and other build output don't belong under source control, for numerous reasons.

share|improve this answer
4  
a) is often not possible of course blogs.msdn.com/b/ericlippert/archive/2012/05/31/… –  jk. Jun 7 '12 at 7:55
    
@jk: nice link. I guess having the source code and all input files for the build stage fully under source control (and having the right compiler version installed) may be "deterministic enough" in a lot of real-world scenarios (and not enough in others, of course). It is case dependent how important it is to have reproducible binaries bit-by-bit. –  Doc Brown Jun 7 '12 at 9:43

Use an artifact repository for binaries, not a version control system. A specific version of a released binary is not supposed to change over time, hence version control does not make sense since the file(s) wouldn't change.

See for example Maven repositories as a repository to archive/publish/offer releases and other binaries (e.g. such as documentation)

share|improve this answer
    
a specific version of a released source file isn't supposed to change over time either. SCM is a fine place to put the shipped binary, you just store it alongside the source files used to build it. –  gbjbaanb Jun 11 '12 at 13:25
2  
gbjbaanb, SCM stands for "Source Control Management". That should give anyone a hint that these systems are not designed to store binaries but source. If you still want to store binaries, go ahead. I won't. –  mhaller Jun 11 '12 at 16:19
1  
SCM stands for "Software Control Management" but nice try. "source code" is often not just text files, but images, documents, diagrams etc. –  gbjbaanb May 1 at 7:28

Just put them in. There's no problem with that, unless you're using git (which doesn't merge binaries well, so you'll have to manage them yourself) or you're committing them too many times (only commit when it's ready to ship, not everytime you build it).

Most SCMs delta binaries quite well, we used to put a 2Mb resource dll into our SVN and it would delta to a few kb each time.

I hear a lot of arguments that SCMs are for source, not binaries but this is plainly false when you consider most software consists of images, even if they are just icon files. They're binaries, but they are part of the source, so put them in and don't be so dogmatic about it. I also hear that you can just rebuild the binary when needed, often this is the case, but it can be a huge time-wasting effort for older systems that are no longer actively supported. If you have to re-create a system with only older service packs or patches to correspond with the system that was used to build a binary 3 years ago, you'll be glad you added the bin to your SCM back then.

The only time you need to worry about adding builds to your SCM is if you're doing it automatically as part of the build server process - don't do this. You will fill your SCM up with builds that have no benefit to you. Instead only add them when they are released. This way you know exactly what your customer has and you can reproduce any customer-reported issues with the binaries they are using, and not ones that you've rebuilt (using, lets say, latest updates to the compiler or the OS).

share|improve this answer

I don't keep release binaries under version control. Instead I publish them to a well defined location so that other tools and inspect and use them. I do a lot of work in Java, so that means I publish Jars to local Maven repositories. However, I don't use these tools to track what has changed per release. After all, they are binaries and there's not really much to track other than file count.

In order to track changes between releases, I would tag or label releases in my version control system with the version number of the release. But this is really only to track the source files, not the binaries. The binaries are artifacts of the build and do not need to be under version control.

share|improve this answer

The best solution is to make exclusive use of your CI system for all organizationally significant builds (releases, release candidates etc...).

This systematically ties the released binaries to the repository content without having to actually store the binaries in the repository.

For example, if you are using SVN, use the branch-major organizational scheme; do all day-to-day development in /trunk, and create a /tag for each release once it is ready.

Configure your CI system to build from tags as well as from trunk, and get it to write output to a network directory whose structure mirrors the top level structure of the repo:

  • /builds/trunk/[rev][date][build_id]/
  • /builds/tags/release_0_1_3beta4/[rev][date][build_id]/

The build system will need to treat the /builds/trunk/ directory like a circular buffer, storing the last n builds, deleting old builds as it goes.

The /builds/tags/ directory, on the other hand, is a permanent store. The build artifacts themselves are stored in directories with names generated according to the following scheme:

  • [rev][date][build_id]

where [rev] is the SVN revision ID, [date] is the date in YYYYMMDD format, and [build_id] is a 3-digit unique counter, incrementing from the first build onwards, making each build directory unique.

The process detailed above gives you the following benefits:

  1. Build artifacts are tied systematically to the source that generated them, so you can find the source for a particular build artifact very easily, (and vice versa).

  2. This forms the basis for further release automation. For example, automatic generation of release documents etc...

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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