Unidirectional Agent-Server Communication

Traditionally TeamCity requires a bidirectional communication channel between the server and agents. The server creates an HTTP connection to an agent and sends commands, like start/stop build, etc, while the agent also establishes an HTTP connection to the server and sends build results. While this approach was straightforward to implement, it almost instantly started causing problems to our users. There are two main pain points here:

for the server to be able to open a connection to an agent, the firewall must be opened on the agent machine

the agent can use the HTTPS protocol when the build results are sent to the server, but the server communicates with the agent by a plain HTTP protocol and so far we do not support HTTPS here...

Also it is sometimes not possible to open a firewall, for instance, if the server is installed outside the corporate network, but agents work in the corporate network. For such cases a VPN channel has to be created.

But we're glad to say that all these problems are in the past now! With this EAP build you can enable unidirectional communication (not enabled by default yet), switch all communications to HTTPS and be safe.
You can also view the communication protocol used by a particular agent on the Agents|<Agent Name>|Agent Summary tab, the Details section.

Visual Studio Tests Runner

Visual studio comes with two very similar test runners - MSTest and VSTest. TeamCity supports MSTest out of the box; for VSTest a separate plugin had to be installed.

Given that these test frameworks are very similar, we realized that providing similar user experience for both of them is the right thing to do, so we decided to combine them into a single Visual Studio Tests runner.
Note that after upgrade to TeamCity 9.1, MSTest build steps are automatically converted to the Visual Studio Tests runner steps, while VSTest steps remain unchanged.

Versioned Settings Improvements

We continue improving versioned settings feature. In previous EAP we announced the ability to start builds with settings taken from a feature branch, or a personal patch.
Now it is possible to configure on the project level whether builds started in this project should use the current build configuration settings of whether the settings from VCS are preferred.