New in TeamCity 2018.2: Increased Scalability
TeamCity 2018.1 allows you to set up a “running builds node.” The node handles data coming in from the build agents. There’s also the “read-only node” for handling disaster recovery scenarios.
TeamCity 2018.2 expands this setup further, making it possible to delegate polling of version control systems to a secondary node.
Currently, it may seem a little complicated, but our intention is simple. We want to have a scalable architecture where you can add more nodes to the cluster so that all the nodes are uniform and can perform all the tasks in an interchangeable way. The only exception will be the main TeamCity server where we configure the cluster. Upgrade, licensing, and diagnostics are also handled by the main TeamCity server.
As a step towards this uniformity, there is no “read-only node” anymore, and it is now called a “secondary node.”
The secondary node is just a TeamCity server started with the additional nodeId argument:
TEAMCITY_SERVER_OPTS=-Dteamcity.server.nodeId=<some id> teamcity-server.bat|sh start
See our documentation on how to configure and start a secondary node.
By default, the secondary node acts as a read-only node. It does not change any data, but only shows the user interface in read-only mode. This setup is well-suited for disaster recovery tasks.
Using the Nodes configuration page of the main TeamCity server, it is now possible to delegate VCS repositories polling responsibility to this secondary node. After that, the secondary server will handle all VCS polling related tasks and commit hooks. In some scenarios, this can greatly reduce the CPU load of the main TeamCity server.
Note that if there are existing commit hooks on the main server, you do not need to change anything. The main server will accept the hook and delegate its processing to the secondary node.
Right now, the secondary node cannot handle data from agents like the running builds node can. But this will change in the future versions of TeamCity. Agents’ data handling will be another responsibility for the secondary node.
Subscribe to Blog updates
Thanks, we've got you!
Introducing AWS Connection: A New Approach for Working With AWS in TeamCity
We’ve introduced a new feature called the AWS Connection, which makes it possible to work with AWS credentials more flexibly and safely.
TeamCity 2022.10: Sakura UI, Improved Integration With Amazon AWS, Out-of-the-Box HTTPS Support, Google OAuth Authentication, and More.
TeamCity 2022.10 comes with the Sakura UI enabled by default, introduces many cloud-related features including the AWS credentials management system and out-of-the-box terminal access to AWS EC2-based build agents, and adds important improvements to VCS integrations. Server administrators will love the new streamlined way to implement HTTPS for on-premises TeamCity installations. Also, a new authentication module for using Google accounts and a number of long-requested features have been implemented.
Transition to native Git in TeamCity 2022.04 brings 10x fetch time reduction to IntelliJ Platform
Starting from version 2022.04, TeamCity switched to native Git on the server side for Git VCS connections. The switch should positively impact both performance and overall experience of working with Git repositories on the TeamCity server side.In this blog post, we’ll talk about the reasons for the …
TeamCity 2022.04: Parallel Tests, Improved Integration with Amazon AWS, Built-in Code Quality Analysis, Updated VCS Integrations, and more
TeamCity 2022.04 introduces the new Parallel Tests feature that delivers an extraordinary speed boost when testing your projects. New powerful code analysis features will cut the time you spend on code reviews and increase the maintainability of your projects. Users who run their builds in the cloud…