TeamCity Reviews

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

• It's a very useful, intuitive tool to continuously deploy new builds
• A clean user interface
• It's very easy to use, even for non-build engineers
• Ability to run automated tests as part of the build process
• Easy to pinpoint issues with the detailed logs
• Easy navigation
• Useful to see how the build is progressing and how many tests are left to pass before the build is green

• Improved the quality of builds by running unit tests as part of every build
• Reduced the risks of regression defects by running automated tests as part of the build process

The UI could be more structured, as it is so customisable it is quite easy to get lost around the screens.

I have used this product for over six months now.

Only environment issues which caused failed deployments. Also, if people were connected to the database on the backend, the build would fail.

It seemed a very stable tool with hardly any downtime in the six months I was using it.

Not at all. In fact it was so stable we were able to add and create our own virtual environments each time we needed to deploy. This meant that each user had their own virtual environment, meaning nothing ever got overwritten.

I had no need for it as we had DevOps engineers who fixed any issues.

I used to use Jenkins in a previous job. I started using TeamCity when I changed jobs as that was the tool that was being used, but I preferred TeamCity to Jenkins.

It's fairly straightforward.

It was implemented by an in-house team.

We used to deploy multiple times a day too many different environments. Also, we had offices in Australia who were using it when we were asleep! Effectively we were using this tool 24 hours a day, seven days a week.

Do it! Very easy to use and very stable. A must have tool for any teams using agile methodologies.

The ability to create Build Pipelines and create user groups are the two most valuable features.

• As a business we had a custom build process where the only people with access to the build were our build engineers.
• Teamcity allowed us to create a visual flow of the processes and steps involved in moving a build through its phases.
• The product also allowed us to identify areas for improvement in our process.

This product lacks real reporting for all the information it captures; we should be able to create reports or dashboards for management.

The product captures a lot of information about build processes, but there is no easy way to create/generate reports that can be used by management.

We have been using TeamCity for about 6 – 7 years.

There were no issues with deployment.

There were no issues with stability.

It would be ideal if agents could scale up on demand using a private cloud. The functionality is there for Amazon.

Good.

Excellent.

The setup is extremely straightforward.

In-house implementation.

We evaluated a few other products. The only product that had was a real contender was Electric Commander.

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.

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

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?

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.