Versions Compared

Key

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

...

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 domain 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 Administration | Global Settings page.
  • Notify all TeamCity users to use the new address

Move TeamCity Agent

Apart from the binaries, TeamCity agent stores it's configuration and data left from the builds it run. Usually the data from the previous builds makes preparation for the future builds a bit faster, but it can be deleted if necessary.
The configuration is stored under conf and launcher\conf directories.
The data collected by previous build is stored under work and system directories.

The most simple way to move agent installation into a new machine or new location is to:

  • stop existing agent
  • install a new agent
  • copy conf/buildAgent.properties from the old installation to a new one
  • start the new agent.

With these steps the agent will be recognized by TeamCity server as the same and will perform clean checkout for all the builds.

Please also review the section for a list of directories that can be deleted without affecting builds consistency.

Wiki Markup
{hidden-data

...

}

h3. Integrate with Wiki

You can use [external status widget|Configuring General Settings#addingStatusWidget] 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|Configuring General Settings#addingStatusWidget].

{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}

Anchor
sharebuildnumber
sharebuildnumber

...

  • 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. It is probably not necessary to dedicate more than 8 cores to TeamCity server.
  • Memory: See a note on memory usage. Consider also that required memory may depend on the JVM used (32 bit or 64 bit). You will probably not need to dedicate more than 4G of memory to TeamCity server.
  • 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.);
  • cleanup rules configured
  • 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;
  • total size of the sources checked out by TeamCity daily.

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 than 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 than 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

...

  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). (warning) 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 if you use internal database and you do not want to perform database move.
    • .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/pluginData (optional) if you want to preserve state of various plugins and build triggers
    • .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)

...

  1. ensure the new server is configured to use another data directory and the database then the original server
    At this point you should be ready to run the copy TeamCity server.
  2. run new TeamCity server
  3. upon new server startup do not forget to update Server URL on Administration | Global Settings page. You will also probably need to disable Email and Jabber notifiers or change their settings to prevent new server from sending out notifications
  4. if you need the services on the copied server check that email, jabber and VCS servers are accessible from the new installation.
  5. install new agents (or select some form the existing ones) and configure them to connect to the new server (using new server URL)

See also the notes on moving the server from one machine to another.

...

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.

...

  1. Write a build script that will perform the deployment task for the binary files available on the disk. (e.g. use Ant or MSBuild for this)
  2. Create a build configuration in TeamCity that will execute the build script.
  3. In this build configuration configure artifact dependency on a build configuration that produces binaries that need to be deployed
  4. Configure one of the available triggers if you need the deployment to be triggered automatically (e.g. to deploy last successful of last pinned build), or use "Promote" action in the build that produced the binaries that need to be deployed. Consider using snapshot dependencies in addition to artifact ones and check Build Chains tab to get the overview of the builds.
  5. If you need to parametrize the deployment (e.g. specify different target machines in different runs), pass parameters to the build script using custom build run dialog. Consider using Typed Parameters to make the custom run dialog easier to use.
  6. If the deploying build is triggered manually consider also adding commands in the build script to pin and tag the build being deployed (via sending a REST API request).
    You can also use a build number from the build that generated the artifact.

...

These notes are provided only for your reference and are not meant to be complete or accurate in their entirety.
TeamCity is developed with security concerns in mind and reasonable efforts are made to make the system not vulnerable to different types of attacks.
However, the general assumption and recommended setup is to deploy TeamCity in a trusted environment with no possibility to be accessed by malicious users.
Here are some notes on different security-related aspects:

  • man-in-the middle concerns
    • between TeamCity server and user's web browser: It is advised to use HTTPS for the TeamCity server. During login, TeamCity transmits user login password in an encrypted form with moderate encryption level.
    • between TeamCity agent and TeamCity server: see the section.
    • between TeamCity server and other external servers (version control, issue tracker, etc.): the general rules apply as for a client (TeamCity server in the case) connecting to the external server, see guidelines for the server in question.
  • user that has access to TeamCity web UI: the specific information accessible to the user is defined via TeamCity user roles.
  • users who can change code that is used in the builds run by TeamCity: the users have the same permissions as the system user under which TeamCity agent is running. Can access and change source code of other projects built on the same agent, modify TeamCity agent code, etc. It is advised to run TeamCity agents under users with only necessary set of permissions and use agent pools feature to insure that projects requiring different set of access are not built on the same agents.
  • users with System Administrator TeamCity role: It is assumed that the users also have access to the computer on which TeamCity server is running under the user account used to run the server process. Thus, some operations like server file system browsing can be accessible by the users.
  • TeamCity server computer administrators: have full access to TeamCity stored data and can affect TeamCity executed processes. Passwords that are necessary to authenticate in external systems (like VCS, issue trackers, etc.) are stored scrambled under TeamCity Data Directory and can also be stored in the database. However, the values are only scrambled, which means they can be retrieved by the users who have access to the server file system or database.
  • TeamCity agent computer administrators: same as "users who can change code that is used in the builds run by TeamCity".
  • Other:
    • TeamCity web application vulnerabilities: TeamCity development team makes reasonable effort to fix any significant vulnerabilities (like cross-site scripting possibilities) once they are uncovered. Please note that any user that can affect build files ("users who can change code that is used in the builds run by TeamCity" or "TeamCity agent computer administrators") can make a malicious file available as build artifact that will then exploit cross-site scripting vulnerability.
    • TeamCity agent is fully controlled by the TeamCity server: since TeamCity agents support automatic updates download from the server, agents should only connect to a trusted server. An administrator of the server computer can force execution of arbitrary code on a connected agent.

Restore Just Deleted Project

...

Please note that TeamCity preserves builds history and other data for deleted projects/build configurations for 24 hours since the deletion time. The data id removed during the next cleanup after 24 hours timeout elapses.

Wiki Markup
{hidden-data

...

}

h3. TeamCity Release Cycle

The information below can be used for reference purposes only.

"major" release below means any release with a change in first or second version number (e.g. X in X.X.Y)
"bugfix" release means releases with a change in the third version number (e.g. Y in X.X.Y)

Release stages that we generally have are:
*Available under EAP (Early Access Program)* \- usually available only for major releases, starts several months after previous major release and usually months before the next major release. Typically new EAP releases are published on monthly or bi-monthly basis.
*General Availability* \- as a rule, there are two major releases each year. There are multiple bugfix releases following the major release. Bugfix releases and support patches for critical issues (if applicable) are provided until "End of Sale" of the release.
*End of Sale* \- occurs with the release of a new major version. After this time no bugfix updates or patches are usually provided (except for severe critical issues, if applicable). Only limited support is provided for these versions.
*End of Support* \- occurs with the release of two newer major versions. At this point we stop providing email support for the release.

Dates for the previous releases can be seen at [TW:Previous Releases Downloads].
{hidden-data}

Set Up TeamCity behind a proxying server

...

No Format
    server {
        listen       400;
        server_name  teamcity.public;

        location /tc {
            proxy_pass http://teamcity.local:8111/tc;
        }
    }

Wiki Markup
{hidden-data

...

}see also comment: [http://youtrack.jetbrains.com/issue/TW-11166#comment=27-331468] 
DO NOT USE THIS SETTING: proxy_set_header Host $http_host;  (spoils redirect URLs)
{hidden-data}

Alternative approach is to setup a proxying server to redirect requests to TeamCity server to a dedicated port and edit <TeamCity home>\conf\server.xml to change existing or add new Connector node:

...

In order to achieve similar experience with these tools you can:

  • publish coverage HTML report as TeamCity artifact: most of the tools produce coverage report in HTML format, you can publish it as artifact and configure report tab to show it in TeamCity. If published artifact name is coverage.zip and there is index.html file in it, report tab will be shown automatically.
  • extract coverage statistics from coverage report and publish statistics values to TeamCity with help of service message: if you do so, you'll see coverage chart on build configuration Statistics tab and also you'll be able to fail build with help of build failure condition on metric change (for example, you can fail build if coverage drops).



























Wiki Markup
{hidden-data

...

}
empty lines to allow proper anchor positioning
{hidden-data}