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.
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.
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)
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).
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.
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:
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:
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:
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).
This forms the basis for further release automation. For example, automatic generation of release documents etc...