How does one version control the configuration of a TeamCity project?

In my CruiseControl instances, I have ve开发者_如何学Crsion controlled the ccnet.config file.

When I want to update CruiseControl, I run an "update config" job which fetches the config from version control.

In this manner, the very build process of a release is configuration managed.

I am wondering how to achieve these goals effectively under TeamCity.

I try to keep what ever CI I am using as light as possible and put as much of the running of the build into an msbuild or nant script including running tests, code coverage, etc.

The benefit of this is:

1. The build file is version controlled.
2. You can run the script in any environment.
3. Easier to move between CI environments.
4. Everyone becomes responsible for the build.

This has been introduced in TeamCity 9. Also answered in another post:

Version control (e.g. in TFS) build configuration for TeamCity - is it possible?

I've been wanting a way to source control TeamCity config for a long time. I ended up writing a Windows Service which monitors the configuration directory and commits changes to git.

The project is on GitHub: https://github.com/grenade/teamcity-config-monitor

You might try looking at the folders that are backed up prior to upgrade (or when restoring team city) as those represent the configurations and changes you've made since initial installation.

http://confluence.jetbrains.net/display/TCD4/TeamCity+Data+Backup

Some of the relevant data is actually a database, (and in fact the documentation advises you to point team city to a real database like mysql instead of the default embedded database it uses)

You could try checking those into SVN, but you'll want to stop team city for any check-in actions.