使用 TeamCity 进行颠覆发布管理

Question

We currently use Subversion for our release management, and tag all of our releases (both to QA and to our production servers). However, we'd like to create a single Release directory reflecting our newest release instead. This way we can have TeamCity always pull from the same folder for continuous builds. Also, if someone has to make a quick bug fix to production, they won't accidentally make it to the wrong branch.

For example, below is our current structure with a 'release' folder added. Would there be an easy way to move a tagged branch to 'release' each time, or even have 'release' be a link to the newest release_* version?

Clarification

Here's an example of how our build/release process currently works:

• Today, I release a version of our web app to QA after TeamCity successfully builds it. When doing so, I branch/tag it
• Tomorrow onward, devs continue making updates in the trunk. These will not be pushed to QA until the next QA release
• On Wednesday, our QA team notifies us that they've found a bug. We make a bug fix on the QA branch, merge the change back to the trunk, and push the updated QA branch back to QA. ISSUE #1: TeamCity is no longer working for us since we're in a #'d QA branch
• On Friday, QA approves the release for production, so we publish and branch/tag
• On Monday, a client calls with an issue requiring a small change to production. We make the change in the release branch and merge back to the trunk. ISSUE #2: Once again, we're making a change without TeamCity helping us

Answer 1

I would (and do) take a slightly different approach to this. Source control management is primarily for, well, managing source and treating it as a means of tracking or implying releases can make life a little tricky. This is really the purpose of your continuous integration environment and it does a far better job of it than what SVN does.

I use TeamCity as the means of identifying both path and revision number to pull from SVN. It's easy enough to define this at build runtime and any release to production is always done with caution (ie carefully check both path and revision). In the absolute worst case, if you do screw it up, you can always re-run the build with revised parameters.

You really don't want to end up making code changes directly to a "Releases" folder - this is what the trunk is for if it's mainstream development or branches are for if you've had to adjust an earlier revision. It's sort of beating SVN into submission to do something that's not its core strength, On that front, you might find some of the tips in The 10 commandments of good source control management useful.

Answer 2

You can easily script this so that after build completion you can copy a file or contents of a folder into release folder. You can even delete the contents of the release folder before doing this. So yes, since a branch or tag in svn is a copy operation you can do this easily.

Answer 3

For each project we have a Latest folder that contains, well, the latest version (usually just the binaries).

This is extremely useful for continuous integration although we have to use custom MSBuild scripts to achieve this eg do a Svn delete on the contents then an Svn copy to the Latest folder.

Answer 4

You can use the svn:external property to have a folder called release point to a different tag. See svn:external .

svn propset svn:externals 'release http://my_repo/tags/latest_tag' .

You would have to update the property value to point to the latest tag each time a new tag release was made.