TeamCity Reviews

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.

• 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.

• Good visualization of builds
• Easy configuration
• Good integration with IDE and JetBrains products

People react faster on failing builds.

I would suggest creating simple and advanced configurations. Advanced configurations will give more customizations like Jenkins does.

Generally no, just in a few cases.

No, adding new build agents were enough.

I would give technical support an eight out of 10. They provide help quickly.

At another company, we switched from Jenkins to TeamCity because of the support.

The setup is straightforward.

If you can, try it out first.

Jenkins.

Try to think about pipeline before buying this product, you can set it up on one machine and try it out.