TeamCity Reviews

VCS Trigger: Provides excellent source control support. Able to customize a feature with the specific conditions we want. For example, if we wanted only a specific branch to trigger a build, we can do that. 

Automatic VCS Triggers, MSTest, and NUnit integration made our workflow much faster and efficient. It just felt more mature and everything was working as we expected.

The upgrade process could be smoother. Upgrading major versions can often cause some pain.

We did not encounter any serious issues with stability so far.

No issues with scalability. When we needed more agents, we simply used pre-configured machines and quickly installed the agent on them.

Great tech support with quick response times.

TFS, back at the time TFS carried too much overhead for us. So, we looked for a better solution out there. When we discovered TeamCity, it totally speeded up our workflow. TeamCity's configuration and ease of use are way better compared to TFS, which eventually saved us a lot of time. 

One of the things I liked about TeamCity. It is very easy to install and maintain.

Start with the free tier for a few build configs and see how it works for you, then according to your scale find the enterprise license which fits you the most.

Jenkins, but it was not mature enough and did not meet our needs at that time.

It really is dependent on your product needs. Do market research and see the pros and cons versus open source or any other solutions out there.

• Continuous integration
• Build templates
• Triggers
• Plugins
• Platform independence

We used do all of our product development builds using .net and Java languages. It is very useful to setup build agents in a Unix platform for all kinds of Unix builds.

Deployment functions need work.

I've used it for two years.

We had an issue when we customized TeamCity for deployment functions in a Windows environment using PowerShell scripting.

No issues encountered.

No issues encountered.

Good. I would give them a 9/10.

Good. I would give them a 9/10.

No previous solution was used.

Simple and easy to integrate with Subversion source code tool.

We used an in-house team whose expertise was 9/10.

It was simple and easy to use. Great features which are always customizable.

We're using it for CI and automating build pipelines.

• Rerun failed tests after overnight execution, saving manual re-execution time during working hours.
• Run acceptance tests after each commit, giving quick and automatic feedback on software quality.
• Automate build pipeline process, removing human errors from the process itself.

Setting up build configurations involves too many steps, as the process is too much broken down. We could do with the same number of steps but less groups.

I've used it for about two years.

I'm not in charge of this, I have updated TeamCity once and it seemed like a quite straightforward task (but slow, due to the DB backup) once I found the online walk-through.

No issues.

It's working perfectly with multiple projects running continuously on five build agents.

I've never had to use customer support.

The user guide is quite thorough and extensive. Some topics are hidden a little bit, but after a while all the queries are answered.

No previous solution was used.

After updating TeamCity, the setup process was quite straightforward, guiding me step by step through the configuration of the new tool.

It was an in-house implementation.

It is vital to our business to have quick and robust builds, and TeamCity is helping us to keep everything tidy and under control.

An FAQ section with all the most common issues/most asked technical questions would be more than welcome.

Features I really like:
Branch builds for Git repositories, shared resource locking, customization via plugins and meta-runners, and storing build configurations per-branch for Git code repositories.

TeamCity allows us to have self-sufficient development teams that can create their own builds and deployments. TeamCity has really allowed us to embrace continuous integration (even running full CI on all code branches with no extra effort).

Features I would like to see in TeamCity:
Allow for shared resource locks across multiple build configurations (i.e. deploy then run integration tests against the same environment).

Allow shared resource locks to accept parameters for dynamic assignment of locks.

• Ease of configuring complete build chains with the use of build templates
• Creating a single custom build runner that allows us to have a single entry point and filter steps by arguments for all our builds
• The ability to trigger subsequent builds in a chain based off of multiple types of triggers in a deterministic fashion

Creating a meta-runner to use as a single build entry point. The templates allow a consistent configuration on how an application is built, and by combining the use of the meta-runner and build templates, the whole organisation understands, and follows, this convention. By following this convention, a complete build stack is completed in a single REST call.

• Client side load as projects/builds with a lot of test history, and branches can take quite a bit of time to load
• It would also be nice to have a conditional build step: https://youtrack.jetbrains.com/issue/TW-17939
• Having project templates

I used it for three years.

You shouldn't use TeamCity as a deployment tool.

As versions progress, TeamCity has greatly improved it's stability with it's resourcing. Also following JetBrains' documentation about how to set up TeamCity, distributes load in a more even fashion.

There have been times when making copies of a project has caused major stability issues, especially when you have nested project structure based off of different build configuration templates.

I've never needed to deal with customer service.

YouTrack has been a great forum to raise/track issues.

We previously used CC.Net. TeamCity provided a much easier method of configuration as well as templating over CC.Net.

If you want just a basic setup, it is extremely straightforward. If you require optimizations such as I/O distribution, you will need to do a little bit more work.

We implemented it in-house.

There’s loads of valuable features but PowerShell Runner is invaluable.

It increases the visibility and clarity of build and deployment activities.

.net deployment needs improvement. Also, I'd like to see more NuGet/Octopus style features and Azure stuff.

I've used it for over five years.

It's all currently hand rolled in PowerShell.

Never ever had any stability issues.

I have encountered some issues using large number of agents, and using git.

The agents are amongst the best available/experienced around.

The agents are amongst the best available/experienced around.

I have used Jenkins, TFS, Cruise Control .net, and GO. I switched from using Cruise Control .net as TeamCity is easier to use and displays important information very well. It also has great support for integrating to other products, from JetBrains and other vendors – Atlassian, JIRA, and Windows AD.

It's very, very simple.

Setup is the licence (and my contract rate).

I have used all leading CI tools.

With low costs to adopt what are you waiting for?

The support for cross-platform builds is very valuable, as is the flexibility in creating build steps. We love that we can include unit and integration tests as part of a build configuration! The plugin functionality is great too, and we couldn't live without the Octopus Deploy plugin.

With Teamcity, our build/packaging process and the ensuing deployment via Octopus Deploy takes less than half an hour. We have a customer base of approximately 40,000, spread over hundreds of virtual machines, so a fast deployment with little to no downtime is critical.

It'd be great to see future built-in support for Octopus Deploy. Currently, Octopus Deploy provides a plug-in for TeamCity, but the installation is manual, and requires a restart of the TeamCity service in order to complete the installation. This is really the only small improvement I would recommend, but it's obviously not a deal-breaker.

I've used TeamCity for approximately one and a half years.

While I didn't take part in the original installation of TeamCity at my current employer, I have set it up on various machines for testing/trial purposes. I use it regularly for a personal project that I maintain. The installation and setup of an initial build configuration were both very straightforward.

No issues encountered.

No issues encountered.

I haven't had the opportunity to interact with support team at JetBrains, but I am impressed with the extent of the documentation.

I haven't been in a situation which required the assistance of the JetBrains technical support team.

It was in place before I arrived at my current employer, but I know that the deployments were handled largely through robocopy scripts that took hours to run. Deploys were typically done in the wee hours of the morning, and required having multiple developers on-site/on call.

I've found the installation to be very straightforward.

The installation was handled as a joint effort between our in-house development and IT teams.

If you need an enterprise build management tool, and your budget permits, it's absolutely worth looking at. Even for independent developers with a limited budget, JetBrains allows you to use the product for free up to a certain number of projects. I use it for a personal project at home, and love it.

Automating continuous integration and catching those culprits who introduce build errors or test failures who refuse to test on their own machines.

Being the sole TDD developer in an organization is not enough if the rest of the team does not test as well. Using TeamCity and emailing everyone on fail is one way to emphasize the importance of testing code and showing management why taking the time to test actually does saves time from having to fix bugs on the other end.

The three best features are the following:

• Automated builds triggered on check-in
• Execution of unit tests with code coverage reports
• Automated deployment to various environments.

Last time I used it, dotnet compilation had to be done via PowerShell scripts. There was actually a lot that had to be scripted. Whether to present an error code or just throw an exception, it was unclear, as well as having to paste a script versus executing a PS file. Fewer "options" in this section with greater consolidation and handling would be appreciated.