Should we tag our SVN repo after every successful CI build?

Question

Tags in SVN are cheap. Are they cheap enough to enable us to tag every successful build that pops out of our CI box (TeamCity, if that makes any difference)?

Answer 1

My answer is NO. This is not SVN specific, it is just good practice specific.

CI builds shouldn't increment build or version numbers - they are just a sanity check that everything builds (hey, it may not run though). There is absolutely no point in tagging a CI build.

Edit:

our QA department pick the next available build from the CI box

Your QA department shouldn't be touching a CI build, instead they should be working with release quality builds, which frequently have more done to them than CI builds (i.e. version numbers have been inserted where appropriate, compilation has been done in Release mode instead of Debug, etc). Remember that CI builds may compile, but they can be a pile of junk, depending on what has been checked in to the source repository.
It sounds like what you refer to as the CI build should just be called the build, as it is the only one you are doing. It is a bit of work to put together a good set of builds, but it is worth the effort, There are a number of tutorials and white papers out there about this, invest some time and read up on it, then give your QA department the smack every time they utter the words "CI build" (as those builds should be for developers use only).

---

Further edit:

a couple of people have commented "why can't a CI build be release quality?". I will try to answer this in a succinct way without turning this into a discussion unsuitable for SO. Let me say first-up that of course a CI build can be release quality. If you can achieve this then more power to you, award yourself a medal. If you are in this category then i would guess that you are on a small team with a slowly changing codebase.

To quote Wikipedia:

Normal practice is to trigger these builds by every commit to a repository, rather than a periodically scheduled build. The practicalities of doing this in a multi-developer environment of rapid commits are such that it's usual to trigger a short timer after each commit, then to start a build when either this timer expires, or after a rather longer interval since the last build.

And to quote Martin Fowler:

Continuous Integration is a software development practice where members of a team integrate their work frequently, usually each person integrates at least daily - leading to multiple integrations per day. Each integration is verified by an automated build (including test) to detect integration errors as quickly as possible.

Neither of those say that a CI build shouldn't be release quality. But nor do either of them say that it should be.

When working in a reasonable size team who are working off the same branch, it quickly becomes impractical to achieve release quality with every CI build. CI builds are invariably started a small period of time after a check-in, there is no guarantee that a team member has actually finished their check-in, or that someone else hasn't started when that timer ticks over and the build starts.

Another thought to bear in mind is that when working on a larger team, a routine pratice is to do CI builds on the development branch, while Release/QA quality builds are done off a Release or QA branch. This enables the dev team to continue implementing features without polluting the builds that QA will be testing - when the features are complete then they get merged across to the branch that the QA team takes their builds from.

_{I hope this explains my comment about QA teams not working with CI builds. Any further discussion should really take place on programmers.stackexchange.com or elsewhere.}

Answer 2

Since Subversion has essentially built-in tag in the global revision number for each commits, this isn't necessary.

You usually tag for marking a significant step, not for keeping track of a continuous process.