|You are viewing documentation of TeamCity 5.x, which is not the most recent released version of TeamCity. Please refer to the listing to choose another version.|
In this section:
Integrate with an issue tracker
Dedicated support for YouTrack, Jira, Bugzilla. You can also turn any issue tracker issue ID references in change comments into links. Please see Mapping External Links in Comments for configuration instructions.
Share the build number for builds in a chain build
Suppose you have build configurations A and B that you want to build in sync: use same sources and take the same build number.
Where <btID> is the internal ID of the build configuration C. Please refer to the Build Configuration page for description of how to determine build configuration ID.
More on dependency properties.
We plan to provide more option on build number sharing. Please watch/comment on TW-7745.
Use an external tool that my build relies on
Assume, to run a build you need to use specific external tool to be installed on a build agent. To solve the problem, you have the following options:
Install Multiple Agents on the Same Machine
If you want to install several TeamCity build agents on the same machine, please consider the following:
For installation instructions, refer to Setting up and Running Additional Build Agents.
Change Server Port
See corresponding section in server installation instructions.
Make temporary build files erased between the builds
Update your build script to use path stored in
Retrieve Administrator password
On the first start TeamCity displays Administrator Setup page. TeamCity installation should always have a user with System Administrator role in the current authentication scheme.
In rare cases on user authorization scheme switch there can be no System Administrator on the system. In this case you may setup one as follows:
If you forgot Administrator password and use internal database, you can reset the password using the instructions.
Ho do I clear build queue if it got too many builds due to a configuration error
Try pausing the build configuration that has the builds queued. On build configuration pausing all its builds are removed form the queue.
Watch Several TeamCity Servers With Windows Tray Notifier
TeamCity Tray Notifier is used normally to watch builds and receive notifications from a single TeamCity server.
In situations, when you have more than one TeamCity server, and want to monitor them with Windows Tray Notifier simultaneously, you need to start a separate instance of Tray Notifier for each of the servers from the command line with the
See also details in the issue tracker.
Estimate hardware requirements for TeamCity
The hardware requirements differ for the server and the agents.
The agent hardware requirements are basically determined by the builds that are run. Running TeamCity agent software introduces requirement for additional CPU time (but it can usually be neglected comparing to the build process CPU requirements) and additional memory: about 150Mb. Although, you can run build agent on the same machine as the TeamCity server, the recommended approach is to use a separate machine (though, it may be virtual) for each build agent.
The server hardware requirements depend on the server load. The load on the server depends significantly on the type of the builds and server usage, so here are only some general guidelines.
As you will probably use external database, you will also decide where the database engine will be running (e.g. same machine, dedicated machine or existing database server). If you choose to run the database engine on the same machine, you should consider hardware requirements with database engine requirements in mind.
If you face some TeamCity-related Performance issues, they should probably be investigated and addressed individually. e.g. if builds generate too much data, server disk system might need upgrade both by size and speed characteristics.
Overview on the TeamCity hardware resources usage:
The load on the server depends on:
Based on our experience, a modest hardware like 3.2 dual core CPU, 3.2Gb memory under Windows, 1Gb network adapter can provide acceptable performance for the setup:
However, to ensure peak load can be handled well, more powerful hardware is recommended.
HDD free space requirements are mainly determined by the number of builds stored on the server and the artifacts size/build log size in each.
If the builds generate large number of data (artifacts/build log/test data), using fast hard disk for storing .BuildServer/system directory and fast network between agents and server are recommended.
The general recommendation for deploying large-scale TeamCity installation is to start with a reasonable hardware and add more projects to the server gradually, monitoring the performance characteristics and deciding on necessary hardware or software improvements. Anyway, best administration practices are recommended like keeping adequate disk defragmentation level, etc.
If you consider cloud deployment for TeamCity agents (e.g. on Amazon EC2), please also review Setting Up TeamCity for Amazon EC2#Estimating EC2 Costs
Setup TeamCity in Replication/Clustering Environment
TeamCity does not provide specific support for any of replication/high availability or clustering solutions, however you can replicate the data that TeamCity server uses and prepare to start a new server using the same data if existing server malfunctions.
When setting up TeamCity in a replication environment please note that TeamCity uses both database and file storage to save data. You can browse through TeamCity Data Backup and TeamCity Data Directory pages in to get more information on TeamCity data storing.
Basically, both TeamCity data directory on disk and database that TeamCity uses should remain in a consistent state and thus should be replicated together.
Only single TeamCity server instance should use database and data directory at any time.
Please also ensure that the distribution of the backup server is of exactly the same version as the main server.
See also information on switching from one server to another.
Move TeamCity projects from one server to another.
Generally, moving projects to a server that already have projects/build configurations configured is not supported. For addressing simple cases manually, please see a comment.
Automatically create or change TeamCity build configuration settings
If you need a level of automation and web administration UI does not suite your needs, there are two possibilities:
Attach Cucumber reporter to Ant build
If you use Cucumber for Java applications testing you should run cucumber with --expand and special --format options. More over you should specify RUBYLIB environment variable pointing on necessary TeamCity Rake Runner ruby scripts:
If you are launching Cucumber tests using Rake build language TC will add all necessary cmdline parameters and env. variables automatically.
Get last successful build number
Use URL like this:
Move TeamCity installation to a new machine
If you need to move existing TeamCity installation to a new hardware or clean OS, it is recommended to follow instructions on copying the server from one machine to another and then switch from the old server to a new one. If you are sure you do not need the old server data you can probably perform move operations instead of copying.
A usual advice is not to combine TeamCity update with any other actions like environment or hardware changes and perform the changes one at a time so that if something goes wrong the cause can be easily tracked.
Generally it is recommended to use a domain name to access the server (in agent configuration and when users access TeamCity web UI). This way you can update the DNS entry to make the address resolve to the IP address of the new server and after all cached DNS results expire, all clients will be automatically using the new server.
However, if you need to use another server address, you will need:
Create a copy of TeamCity server with all data
One of the ways to create a copy of the server is to create a backup, then install a new TeamCity server of the same version that you already run, ensure you have appropriate environment configured, ensure that the server uses own TeamCity Data Directory and database and then restore the backup.
If you do not want to use bundled backup functionality or need manual controll over the process, here is a description of the general steps you will usually need to make to create copy of the server:
Note: if you want to do a quick check and do not want to preserve builds history on the new server you can skip step 6 (cloning database) and all items of the step 5 marked as optional.
At this point you should be ready to run the copy TeamCity server.
Please note that TeamCity Data Directory and database should be used by a single TeamCity instance at any given moment. If you configured new TeamCity instance to use the same data, please ensure you shutdown and disable old TeamCity instance before staring a new one.
Test-drive newer TeamCity version before upgrade
It's advised to try new TeamCity version before upgrading your production server. Usual procedure is to create a copy of your production TeamCity installation, then upgrade it, try the things out and when everything is checked, drop the test server and upgrade the main one.
How do I chose OS/platform for TeamCity server?
Once the server/OS fulfills the requirements, TeamCity can run on any system. Please also review the requirements for the integrations you plan to use (e.g. integration with Microsoft TFS and VSS will work only under MS Windows)
If you have no preference, Linux platforms may be more preferable due to more effective file system operations and the level of required general OS maintenance.
Final Operating System choice should probably depend more on the available resources and established practices in your organization.
If you chose to install 64 bit OS, TeamCity can run under 64 bit JDK (both server and agent).
How do I setup deployment for my application in TeamCity