TeamCity Reviews

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?

• Templates
• Meta-runners
• Plugins
• Multiple version control system support
• REST API support

We can build our code daily and automatically, with email notification for failures. It's easy to move to a new release because of templates and meta-runners, and agent pooling.

REST API support lacks many features in customization of builds, jobs, and settings. 

Also, integration with newer technologies needs improvement.

Depends on the server host, but it runs on Java so it needs high specs. Otherwise, the website takes a long time to load. 

Also, supporting newer technologies is limited.

You have to clean up old projects, otherwise the load on the server increases with increase in size of projects.

Technical support is good.

No previous solution.

Straightforward, the documentation on the website is very helpful.

I don't handle pricing so I can't really advise on this.

We did not evaluate other options but we may consider moving to Jenkins because it's free and has many similar features.

Use Templates and meta-runners, they are very useful in scaling your product with new releases.

We primarily use the solution for application building and testing, continuous integration testing, and continuous delivery.

The most valuable aspect of the solution is its easy configuration. It also has multiple plugins that can be used especially for building .net applications.

Some of the configurations have room for improvement. They are partly calling another tool via the command line and the parameters on the command line are occasionally hard to use.

If there was more documentation that was easier to locate, it would be helpful for users.

I've been using the solution for five years.

In the prior version, there were some problems with the doc agents, but the latest version is quite stable.

We're not a big company, so we don't need to scale in a big way. It is possible to partly scale by adding multiple agents within the license. It would be quite easy to do this if you need to.

We've never used technical support. We haven't needed to use it yet.

The initial setup was straightforward.

Our company handled the implementation.

We use the on-premises deployment model.

I'd advise others that it's absolutely necessary to use an integration tool that can run integration tests. 

I'd rate the solution eight out of ten.

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.