TeamCity Reviews

We are using the latest version of TeamCity by JetBrains, 2021. 

We needed CI/CD, a Continuous Integration Delivery approach to our current process and the database development process. We needed a tool to generate and run automated builds and tests and to notify us in the event of a failure.

The integration is a valuable feature. The solution comes with a great CI/CD flow. As we have our own personal server, we have our own account for each developer. When it comes to access to it's dashboard it can be integrated with a social control. We integrated with version control and did so with GitHub. It allows one to have repositories in a single place, so as to customize the whole desired flow for having an initial continuous integration of a working build.

We would like to see better integration with other version controls, since we encountered difficulty when this was first attempted. This meant that we had to use predefined scripts that we wrote on our own.

When it comes to other source control tools , such as GitHub, it's really straightforward and easy to do.

We've been using TeamCity over the past 12 months. 

The initial setup was straightforward. I can log in and start working as soon as I have my account credentials. While some advance training is needed, the person would be good to go once he has mastered the basics. 

When it comes to plans to increase usage, this depends on the company and the user developer.

I have not had occasion to make use of the solution's technical support. 

The licensing is on an annual basis.

I cannot comment on the pricing, as this is out of my purview. 

We did not evaluate other options prior to going with TeamCity. It was the first one we picked for the integration of our CI/CD.

We have more than 50 users in our organization who are making use of the solution.

There is much online documentation for TeamCity, with certain learning materials such as videos. There are many free courses, as well.

Someone considering the implementation of TeamCity should first define all of his use cases. If the person wishes to integrate it with infrastructure, but is a junior engineer who lacks experience with DevOps tools, he would need to do some learning. This said, the solution is a great tool for CI/CD. 

The solution has all the features that I need, with a good user interface. I'm pretty satisfied.

I rate TeamCity as an eight out of ten. 

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.