Igor,

Actually, build configurations are stored in XML format in the .BuildServer/config/<projectName>/project-config.xml file.

As a workaround, you can edit the files manually.
With some caution, you can edit the the files (server restart is not needed, all the changes should be picked up on the fly). Be sure not to breakl the XML structure and provide new "id" for the "build-type" if you create new build configurations.

Probably some UI to download/upload build configurations in .xml files (part of project-config.xml and VCS roots)

Some notes on manual moving projects from one server to another.

There is no feature to add build configuration settings from one TeamCity server to another. Please plan your TeamCIty deployment in advance with this in mind.

With some manual work it is still possible to transfer project and build configuration settings. This approach is described below, but it requires careful XML editing and can be used only if you need to transfer many projects with complex settings. It's usage is not recommended and is discouraged.



For the time being it is not possible to transfer builds information (history, artifacts, etc.)

Both the source and the target TeamCity servers need to be exactly the same version (build number).

For the settings transfer, you need to get a set of files from .BuildServer\config directory from TeamCity data directory or source server, modify ids within xml files and put it in the corresponding place of TeamCity data directory of target server. You can do this even without server restart.

The files to process:
Directory: .BuildServer\config\<your project name>
You can safely drop project-config.xml.* files
In the file project-config.xml you might need to modify the tags listed below to ensure ids do not clash with ids on the target server.

<project id="project58">
 <build-type id="bt133"...
...
    <vcs-entry-ref root-id="10"...
...
    <settings>
      <artifact-dependencies>
        <dependency sourceBuildTypeId="bt413" ...
...
      <dependencies>
        <depend-on sourceBuildTypeId="bt363" />
 ...
      <build-triggers>
        <triggered-by buildTypeId="bt365" />
...

Relevant tags of a file: .BuildServer\config\vcs-roots.xml
This file stores all VCS roots. From this file you will need to get the "vcs-root" tags that are referenced in "vcs-entry-ref" subtag of "build-type" tag in project-config.xml file, probably modify the ids in both places and add the resulting vcs-root into .BuildServer\config\vcs-roots.xml file on the target server.

Basically, all the references by id's need to be updated. They can be configured in various places around the system including user-specified configuration settings (e.g. "dep.btXX." properties references), plugin-settings.xml file, etc.

To preserve the current build numbers, you will also need to update names of "bt132.buildNumbers.properties" files to have the ids as in corresponding "build-type" tags of project-config.xml files.

Please create backup copies of all modified data. Backup of the target server is also recommended.

See also a section of our doc that describes .BuildServer directory files.

Ans one more request for servers merge.

One more request www.jetbrains.net/devnet/message/5262213

I would love to see these functionality. A little more background information:
We currently use TC 6.5 Prof.

We have a few projects/builds which are used all the time and many other which are only needed temporarily. However the configuration of the projects/build is rather complex. It would be cool if we could export them if we don't need them anymore, so we could just delete them. If we would need them later (e.g. new development after a year) we could simply import it again. In this case we don't mind to loose the history, artifacts, ... Only the configuration is important.

I'm afraid we also are doomed to go through this painful migration exercise pretty soon, as we have 2 TC installations that need to be merged.
The possibility to keep history and logs (not artifacts) would be great feature for us, as I'm not sure I will be able to persuade dev teams to accept loss of them.

But there is also another thing that would be nice to migrate (export\import) - definitions of Groups. In our case we have 1 Group for each project called "<project> developers" containing "Project Developer" Role for that project. So we just include people (their User names) into specific Groups to give them access.
I found only Roles definitions in .Buildserver/config/roles-config.xml, so I guess Groups and their Users are stored somewhere in the database.

Ivan,


Unfortunately, so far there is no technical ability to implement this in foreseeable future.

Users and user groups are stored in the database. In theory, the data can be moved manually in the database format, however editing database directly is not recommended. Another alternative would be to write a Java plugin that will use openAPI to create necessary groups)

a request to copy configurations between different TeamCity versions
devnet.jetbrains.net/thread/433695

also requested in devnet.jetbrains.net/thread/435303

also related: devnet.jetbrains.net/message/5453386