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. 

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.

Creating build environments for a various range of embedded (C/C++) products with multiple build agent configurations. Empowering the integration team (verification testing) with the ability to test subsystems of applications before launch.

The flexibility of TeamCity allows it to fit in workflows that I have yet to imagine. As we learn how to configure the build processes to fit our needs, it will prove to be a significant time saver.

TeamCity has a remote build feature that we have used to support legacy products (that use compilers that cannot run on current OS versions).  Rather than having developers locked into an outdated PC for legacy support, we now only need to support a single VM that is configured as the build agent for the legacy product.  TeamCity provides integrations for Eclipse, but in our case, it worked better to create a Python script that provided the necessary interaction between SlickEdit and TeamCity.  Developers can make code changes on a current Windows or Linux system, and changes made locally are pushed to the build agent as a personal build.

We are also exploring capabilities of use of the "Report Tabs".  To ultimatly support FDA compliance concerns, I have a prototype of an HTML report being generated that includes CRCs, SCM URLs, SCM Revisions, etc for all items of a build chain.

Their online documentation is fairly extensive, but sometimes you can end up navigating in circles to find answers. I would like them (or partner with someone) to provide training classes to help newcomers get things up and running more quickly.

Have not experienced any "failure" of TeamCity.  An occasional lack of responsiveness from the web interface happens from time to time.  May have been appropriate to provide more CPU resources when the VM was originally created.

At the Enterprise licensing level, there are no limits to the number of, or complexity of the build configurations that can be set up.

For billing & license renewal questions, their Customer Service is very responsive.  Technical support is also available for Enterprise users, but have not had a need to use it more than once or twice.

No, we were new to CI/CD.

Installation was reasonably straight forward using information from their web site.  Our installation was built in a virtual environment (VMware ESXi/vCenter) and is running on a RHEL 7 minimal installation using MariaDB.

TeamCity was implemented in house with support only from their web documentation.

Jet Brains allows using their product at no charge, but with a cap on build agents, and the number of build configurations allowed, so you can explore the capabilities before committing.  Our current licensing level allows up to 10 simultaneous build agents running, and unlimited build configurations for less than $2000 per year; although not free, it seems a very reasonable cost for the horsepower delivered.

Yes, considerations were given to open source products (Jenkins/Hudson, go.cd ...).  It did not appear that any of the others considered could provide an equivalent of the remote build feature offered by TeamCity.

Wish the Tomcat server could magically convert to HTTPS (instead of the apparent default of HTTP).

There are published works on using TeamCity (separate works by authors Melymuka and Mahlingam, both on Packt Publishing), however both of these are out of date which makes the initial learning curve more challenging.  I invite these publishers to update their work; would gladly purchase updated revision.

I've used TeamCity for many years at three different companies. This has been mainly for CI -building and testing software, but also for CD - continuous delivery and deployment. This has included .NET, Java, Ruby on Rails applications, running database scripts, and basically doing anything that can be automated.

It provides repeatable CI/CD throughout our company with lots of feedback on failures and successes to the intended audiences via email and Slack. This speeds up release cycles tremendously. Also, it helps when it comes to PCI/auditing (if set up correctly), as TeamCity has great security and tracking model.

The most valuable features are:

• Build chains - it's really easy to set up all of your build dependencies
• Snapshot dependencies and triggers - you always build the correct code as a snapshot is taken at the moment you run the build chain (i.e. no unexpected check-ins are included in your build!)
• Templates - for setting standards and making the configuration easy and clean
• Meta runners - sharing code 

TeamCity is very stable, is easy to set up and maintain. Once everything is configured there is almost zero time needed to maintain it.

It will benefit this solution if they keep up to date with other CI/CD systems out there. Although I think TeamCity has everything anyone would need, and covers almost every scenario, it needs to keep evolving just to appear to be in sync with others.

Also, more marketing would be helpful just to get the word out on what an amazing product TeamCity is.

This is a very stable solution.

The initial setup is easy and there is almost no maintenance.

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.

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.

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