TeamCity Reviews

For my company, we require a CI server that's very flexible. Our bills are simple, almost template-based, however, we need to be able to deploy to almost any platform, basically whatever the customer could end up using, whether it be Windows, Mac, Android, and even mobile or tablets, et cetera. We can do it with this solution. 

It needs to be simple because right now as I am the only IT person knowledgable of infrastructure on the team. If we need to build a pipeline, it needs to be simple enough that the rest of the team would be able to understand and work with it.

The solution has been fantastic for our organization due to the fact that we do not need a designer having to build the product. We don't need to figure out how to deploy it either. It's created improved efficiencies which have saved us time and expense.  

TeamCity is very useful due to the fact that it has a strong plug-in system.

It's fantastic how simple it is to set up a pipeline. You don't need to be a technical user to understand the process and make it work and to create and build steps within the pipeline.

Harness stuck out to me due to the fact that it looked like testing and deployment was very simple and out of the box. TeamCity it definitely isn't plug and play. It's not a few clicks and you're done. It takes a bit more work.

If TeamCity could create more out of the box solutions to make it more user friendly and create more use cases, that would be ideal.

I would like it if they had a better system for copying or editing what has already been created. Right now it's either too simplistic, or you have to go through several steps just to delete something and to copy something that either does a whole copy or almost nothing. There is no in-between. You can't choose how much of something you take. I would prefer if there was more of, "okay, copy all of this, but leave out these steps." That would just make things a lot faster.

We've been using the solution for about a year now.

The solution is reliable. I don't recall bugs or glitches. It doesn't crash. It's stable.

The solution is scalable. If an organization needs to expand it, it's possible to do so.

Currently, we have 10-12 users on the solution. These include the creative design team, software engineers, and project managers.

The technical support is good. It's forum based. You post on their websites. You don't really create a ticket and you don't call anyone. You post on their website someone will help you by answering your question there. Then, everyone can also see the answer.

The solution is a little bit complex. It's not quite straightforward. You have to set up servers and agents. Essentially, you need three computers to get up and running.

We did not use an integrator or consultant to assist us with the deployment. We managed the process by ourselves.

The licensing costs depend on what you use the solution for, however, it's free to start and you get up to three agents for free. If you want to do more than a hundred builds or a hundred different setups, then you have to pay more or start paying. 

It's a Freemium model. Once you pass the free stage, it can cost anywhere from a few hundred to a few thousand dollars per year.

We're currently looking at Harness, which seems to have a few more out of the box features that we need, so we are considering either integrating the two together, or switching over entirely.

We're just a customer. We're using the most up to date version of the solution currently.

TeamCity is our main continuous integration tool, however, it is deployments that we were looking into improving. With Harness I saw that the deployment process was very polished. And at this point I was wondering if there was any interactivity between the two solutions, or just what would be the benefits of just switching completely to Harness. We're currently researching that now.

I'd advise other organizations to do a lot of research before you begin creating anything.

The solution needs a lot of maintenance in the sense that you need to understand all the different pieces. You need to be able to look at the servers and the agents, and, if you're going to implement anything new, you'll need to understand it is going to take a while to get it right.

I'd rate the solution 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.