VCS worker is a separate service responsible for communication with VCS repositories. The service was extracted from TeamCity core and can now be installed on any machine in the network. TeamCity server can be configured to use one or more VCS workers, in which case some or all VCS specific tasks will be routed to appropriate workers. For example, it is possible to route all Git specific requests to one worker, and Subversion requests to another.
VCS worker is disabled by default and TeamCity behaves as usual, i.e. performs all VCS operations from the main server process.
There is a number of situations when VCS worker can be useful:
Currently worker supports the following operations:
Note that in case of agent side checkout when agent retrieves source code from the repository worker is not used, agents themselves will connect to VCS repository as usual.
In general this component can be useful for large setups as it gives server administrators more flexibility for tasks like server monitoring and scalability.
The feature is in experimental state and can be left in this state even in version 8.0. So far we do not guarantee compatibility between server and worker, if you choose to install worker, most likely you'll need to upgrade it each time when you upgrade server. Also there is no auto-upgrade procedure yet.
If you want to experiment with this feature please refer to our documentation for VCS worker installation instructions: http://confluence.jetbrains.com/display/TCD8/VCS+worker+installation.
Ability to create sub-projects, move project under another project, inherit parameters.
New page was added in Administration area: Server health. Our intention is to provide server administrators with different reports highlighting possible configuration problems. Currently the following reports are available:
Have you ever tried to figure out which project artifacts consumed most of disk space on the server? If so, then you'll appreciate this feature. It shows you the size of artifacts and build logs in each project and configuration, allowing to find hot spots easily.
Build queue is a kind of shadow world of TeamCity. While build stays in the queue, there is no easy way to overview its parameters, changes, dependencies and so on. Internally, a queued build does not differ much from a regular build, so we thought it would be nice to show its details in almost the same way. Now you can click the #number link in the build queue and you'll be redirected to the queued build page with all the familiar tabs:
Our plan is to improve dependencies presentation on this page, and to simplify discovery of state and progress of the current build chain.
We continue improving the shared resources feature. In this EAP we added one more type of resource: resource with custom values. You can now define a resource with several values like this:
You can then add a lock for such a resource by adding the "Shared resources" build feature to a build configuration. The lock can be added to any available value, all values or a specific value. In case of any or specific value, TeamCity will start a build only if the value is available (i.e. no other builds obtained locks for this value). Actual value will become available as a parameter, so you can even use it in the build script. If a lock for all values is selected, TeamCity will start a build only when all values become available. Essentially, this works like a pool of resources – until there are values in the pool, builds can start, once all values are taken, builds will be put on hold.
We've worked hard for a couple of months with our colleagues from the ReSharper team to fix a large set of bugs in server-side .NET code analysis. Generally, all those bugs could be described as "There are no errors (warnings) in Visual Studio, but TeamCity shows a number of problems in my code."
The reason was that the project model which is an input for code analysis was incorrectly constructed outside of Visual Studio. In order to fix this, we now support all of MSBuild-related features usually used by developers.
Some of them are:
There still might be some issues so we are highly insterested in your feedback about this feature!
We have also received issue reports about poor performance of code analysis on the server (compared to ReSharper). To mitigate this, all data produced by code analysis which could be reused in future builds on the same build agent is stored outside of the checkout directory (by default) and is cleaned up together with other agent caches.