Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migrated to Confluence 4.0

...

TeamCity treats equally all agents no matter if they are installed on the same or on different machines. However, before installing several TeamCity build agents on the same machine, please consider the following:

  • Builds running on such agents should not conflict by any resource (common disk directories, OS processes, OS temp directories).
  • Depending on the hardware and the builds you may experience degraded builds' performance. Ensure there are no disk, memory, or CPU bottlenecks when several builds are run at the same time.

After having one agent installed, you can install additional agent by following the regular installation procedure, but make sure that:

  • The agents are installed in the separate directories.
  • They have distinctive work and temp directories.
  • Values for name and ownPort properties of buildAgent.properties are unique.

If you are installing additional agents as services under Windows, modify the <agent>\launcher\conf\wrapper.conf: wrapper.console.title, wrapper.ntservice.name, wrapper.ntservice.displayname and wrapper.ntservice.description properties should have unique values within the computer.

...

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.

...

However, if you need to use another server address, you will need:

  • Switch agents to new URL (requires updating serverUrl property in buildAgent.properties on each agent).
  • Upon new server startup do not forget to update Server URL on Server configuration administration page.
  • Notify all TeamCity users to use the new address

Wiki Markup
{hidden-data

...

}
h3. Integrate with Wiki

You can use [external status widget|Enabling the Status Widget for Build Configurations] to incorporate information about a build status into any HTML page.

For example, to include the status widget into a Confluence page, ensure you have XXX plugin installed that will allow to include HTML snippets into any page and use markup like (do not forget to replace _<values>_:

{code}
{{include-html}}
<style type="text/css">
 @import" <TeamCity_server_URL>/css/status/externalStatus.css";
</style>
<script type="text/javascript" src="<TeamCity_server_URL>/externalStatus.html?js=1&buildTypeId=<buildConfigurationId1>&buildTypeId=<buildConfigurationId2>&buildTypeId=<buildConfigurationId3>">
</script>
{{include-html}}
{code}

TeamCity allows user to display information about current status of a build configuration on a Confluence Wiki page (as well as on any other web-page) [via the external status widget|Enabling the Status Widget for Build Configurations].

{note}Please beware that any information about build configuration published with the external status widget is available for *any* viewer of the page where you've integrated the widget.{note}

Please note that to integrate status widget into the Confluence page or another Wiki page you should have a macros or plugin which allows to insert plain HTML code into the page. For example, in Confluence you can use {{include-html}} macro.
{hidden-data}

Share the build number for builds in a chain build

...

  • Check in the tool into the version control and use relative paths.
  • Create a separate build configuration with a single "fake" build which would contain required files as artifacts, then use artifact dependencies to send files to the target build.
  • Install and register the tool in TeamCity:
    1. Install the tool on all the agents that will run the build.
    2. Add env. or system. property into buildAgent.properties file (or add environment variable to the system).
    3. Add agent requirement for the property in the build configuration.
    4. Use the property in the build script.
  • Add environment preparation stage into the build script to get the tool form elsewhere.

Wiki Markup
{hidden-data

...

}
h3. Measure Coverage of my .Net Code

To measure coverage for your .Net code you can use NCover.
See [Lauren Kempe blog post on the matter|http://www.intellij.net/forums/thread.jspa?threadID=277581].
{hidden-data}

Change Server Port

See corresponding section in server installation instructions.

...

Overview on the TeamCity hardware resources usage:

  • CPU: TeamCity utilizes multiple cores of the CPU, so increasing number of cores makes sense.
  • Memory: See a note on memory usage. Consider also that required memory may depend on the JVM used (32 bit or 64 bit).
  • HDD/disk usage: This sums up from the temp directory usage (<TeamCity home>/temp and OS temp directory) and .BuildServer/system usage. Performance of the TeamCity server highly depends on the disk system performance. As TeamCity stores large amounts of data under .BuildServer/system (most notably, VCS caches and build results) it is important that the access to the disk is fast. (e.g. please pay attention to this if you plan to store the data directory on a network drive).
  • Network: This mainly sums up from the traffic from VCS servers, to clients (web browsers, IDE, etc.) and to/from build agents (send sources, receive build results, logs and artifacts).

The load on the server depends on:

  • number of build configurations;
  • number of builds in the history;
  • number of the builds running daily;
  • amount of data generated by the builds (size of the build log, number and output size of unit tests, number of inspections and duplicates hits etc.);
  • number of agents and their utilization percentage;
  • number of users having TeamCity web pages open;
  • number of users logged in from IDE plugin;
  • number and type of VCS roots as well as checking for changes interval for the VCS roots. VCS checkout mode is relevant too: server checkout mode generates greater server load. Specific types of VCS also affect server load, but they can be roughly estimated based on native VCS client performance;
  • number of changes detected by TeamCity per day in all the VCS roots.

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 following setup:

  • 60 projects and 300 build configurations (with one forth being active and running regularly);
  • more then 300 builds a day;
  • about 2Mb log per build;
  • 50 build agents;
  • 50 web users and 30 IDE users;
  • 100 VCS roots (mainly Perforce and Subversion using server checkout), average checking for changes interval is 120 seconds;
  • more then 150 changes per day;
  • the database (MySQL) is running on the same machine, main TeamCity process has -Xmx1100m -XX:MaxPermSize=120m JVM settings.

However, to ensure peak load can be handled well, more powerful hardware is recommended.

...

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.

...

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

...

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.
This way, the backup will not contain:

  • the build artifacts, so if you need them, you will need to copy .BuildServer/system/artifacts from the original server to the copied server.
  • .BuildServer/plugins - copy the directory if you have it
  • .BuildServer/lib - copy the directory if you have it

If you do not want to use bundled backup functionality or need manual control over the process, here is a description of the general steps you will usually need to make to create copy of the server:

  1. create a backup so that you can restore it if anything goes wrong
  2. ensure the server is not running
  3. either perform clean installation or copy TeamCity binaries (TeamCity home directory) into the new place temp and work subdirectories can be omitted during copying). Use exactly the same TeamCity version. If you plan to upgrade after copying, perform the upgrade only after you have existing version up and running.
  4. transfer relevant environment if it was specially modified for existing TeamCity installation. This might include:
    • if you run TeamCity with OS startup (e.g. Windows service), make sure all the same configuration is performed on the new machine
    • use the same TeamCity process launching options
    • use appropriate OS user account for running TeamCity server process with appropriately configured settings, global and file system permissions
    • transfer OS security settings if required
    • ensure any files/settings that were configured in TeamCity web UI are accessible; put necessary libraries/files inside TeamCity installation if they were put there earlier)
  5. copy TeamCity Data Directory. If you do not need the full copy, refer to the items below for optional items.
    • .BuildServer/config to preserve projects and build configurations settings
    • .BuildServer/lib and .BuildServer/plugins if you have them
    • files from the root of .BuildServer/system (most importantly, version.dat). The file license.keys contains license key, and you can copy it only if you make the copy for backup/evaluation purposes.
    • .BuildServer/system/messages (optional) if you want build logs (including tests failure details) preserved on the new server
    • .BuildServer/system/artifacts (optional) if you want build artifacts preserved on the new server
    • .BuildServer/system/changes (optional) if you want personal changes preserved on the new server
    • .BuildServer/system/caches and .BuildServer/system/caches (optional) are not necessary to copy to the new server, they will be recreated on startup, but can take some time to be rebuilt (expect some slow down).
  6. create copy of the database that your TeamCity installation is using in new schema or new database server
  7. configure new TeamCity installation to use proper TeamCity Data Directory and database (.BuildServer/config/database.properties points to a copy of the database)

...

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.

...