TeamCity Reviews

We use TeamCity for build configuration and pipeline creation, as well as for automation purposes. We provide working pipelines for different teams internally.

We can use multiple types of agents, like Linux-based and Windows-based, which supports all types of languages in scripting when we mention a build step.

TeamCity supports multiple types of agents and scripting languages.

TeamCity's user interface could be improved; specifically, the tree structure on the homepage is not clear, making it difficult to search for projects. Moreover, there are some limitations related to the version we were using. For instance, there were issues with agent specifications for particular build jobs and a timeout issue where jobs running longer than three hours would fail automatically.

I have been using TeamCity for three years.

Sometimes there is latency, particularly when TeamCity is collecting information from different servers, such as under VCS. It occasionally takes time to gather information within the jobs.

For our system, it wasn't scalable due to storage issues. We couldn't often move our data, and we hadn't increased the number of VM machines because of costs, so storage became an issue.

Support was satisfactory. We reached out once or twice regarding backup migration from one server to another server.

Neutral

Previously, we used Bitbucket and TeamCity. Later, GitLab was introduced, but some projects remain on Bitbucket and TeamCity.

The initial setup is fairly straightforward, especially if you have experience in server administration.

Typically, a single person can manage the installation if the instructions are clear.

Compared to new technologies, TeamCity is more expensive and is an older tool compared to tools like GitLab.

We are using GitLab for multiple purposes, including code writing, GitHub-like usage, pipeline running, and code quality checks, all on the same platform.

While TeamCity serves its purpose for small projects or teams that don't require a multi-vendor tool, for larger setups, enhanced features could be beneficial.

We use TeamCity for the CI/CD pipeline. It is used for deploying code from the desktop to the production environment. We push our code to GitHub, which then creates a pipeline to a server using AWS, deploying automatically without errors or conflicts in GitHub branches. 

We also use TeamCity's version controlling for our staging, production, and development environments.

TeamCity has significantly streamlined our deployment processes, allowing for a straightforward and quick path from code development to deployment. By automatically warning us of outdated libraries or errors during the upload, it helps maintain a high standard of code quality and ensures smooth deployments.

The usability of TeamCity is its most valuable feature. It is very easy to use, and its speed is impressive, allowing the code to be ready for production in seconds. Its integration with GitHub ensures clean code is sent to the CI/CD process without any pre-scripting or errors.

I would like to see an improvement where TeamCity alerts us via email or another medium if there are discrepancies between the code in the staging environment and what has been deployed to production, such as missing updates.

I have been working with TeamCity for about one and a half years.

We have not experienced any stability issues with TeamCity. It is a reliable product with quality servers.

We have not faced any scalability issues. We've scaled from ten Lambdas to 500 Lambdas on AWS without any issues.

TeamCity's technical support is quite helpful. The documentation is clear, and the community and tech support provide valuable assistance. I would rate their customer service highly.

Positive

The initial setup was somewhat straightforward yet challenging for those unfamiliar with the process. Experienced users will find it manageable, especially if they have used CI/CD pipelines like Jenkins before. The scripting process needs attention to ensure all stages are covered properly.

We are developers, and the pricing and licensing are handled by upper management, so I do not have direct experience with the costs.

I advise users to ensure they do not miss any steps in the deployment pipeline. Missing steps can lead to issues if changes are not reflected across environments. Prioritize accuracy in code deployments.

I'd rate the solution nine out of ten.

I used the product to deploy changes to UAT for testing and then to production.

The integration between Bitbucket and TeamCity could be smoother. I encountered challenges when passing data from Visual Studio to Bitbucket and TeamCity. Improved documentation or out-of-the-box connectors enhance this process.

I have been working with TeamCity for around one year.

I have experience with other CI/CD platforms, including Jenkins. My work with Jenkins involved setting up pipelines for automated deployments, particularly in a project that managed deployments for a microservices architecture. 

Jenkins provides more flexibility and has a larger community, facilitating troubleshooting and customization. Being open-source, Jenkins allows for a wider array of plugins and customizations. On the other hand, TeamCity is more structured and user-friendly, though it may not offer the same level of flexibility. Nevertheless, both platforms are powerful, depending on the specific use case. 

Security is a fundamental aspect of the deployment process. I ensure that credentials and sensitive data are encrypted and not hard-coded into scripts or configurations. Tools such as Vault or environment variables assist in managing this securely. Moreover, we implement role-based access controls (RBAC) to guarantee that only authorized personnel can initiate deployments or access production environments. For compliance, particularly in regulated industries, I establish audit trails to track changes made and their timing. Automated security scans, such as those using SonarQube or Snyk, are integrated into the CI/CD process to identify vulnerabilities before deployment.

Rollbacks are a critical component of the CI/CD process. In TeamCity, I typically maintain a previous stable build that can be reverted to in case of failure. In Jenkins, I have set up automated rollback scripts that can be triggered if a deployment fails post-deployment tests or if monitoring tools detect issues. Keeping a clear version history in the repository is essential for both platforms, facilitating a straightforward rollback process with minimal downtime.

Post-deployment testing involves automated regression tests, smoke tests, and performance tests. These tests are integrated into the pipeline to ensure that once the code is deployed, the system runs through them to verify functionality. Tools like Selenium for automated UI testing and JUnit for unit tests are often utilized. Additionally, I use monitoring tools to track application performance and to alert us to any issues arising after deployment.

I utilize feature branches for version control, merging them into the main branch only after thorough testing. During integration with Bitbucket, TeamCity fetches the specific branch for deployment, ensuring that only stable versions are deployed. This process minimizes conflicts and ensures a smooth deployment to production environments.

We typically set up automated notifications for build and deployment statuses. For instance, I configure notifications for successful and failed builds sent to our Slack channel or via email. We also integrate continuous monitoring tools like New Relic or Datadog to provide real-time post-deployment feedback on deployments and application performance. Any issues identified through these tools are quickly addressed through rollbacks or patches.

We primarily relied on existing configurations and custom parameters, which reduced the necessity for manual scripting. Nevertheless, I have automated testing scripts, backup processes, and deployment steps in other tools to ensure smooth and repeatable deployments.

I stay informed by reading industry blogs, attending webinars, and participating in community forums. Platforms like Stack Overflow, Reddit, and specific CI/CD tool communities provide valuable insights into new features, troubleshooting tips, and best practices. Furthermore, I prioritize experimenting with new tools and updates in a sandbox environment before introducing them into a production workflow.

Collaboration is essential for a successful CI/CD process. I typically utilize communication tools like Slack and project management platforms like Jira to keep all team members aligned. Regular stand-up meetings, retrospectives, and post-mortem analyses are crucial to ensure the development, operations, and testing teams are coordinated and harmonious. Automation also allows everyone to view real-time deployment statuses and test results, promptly resolving any issues.

Overall, I rate the product a five out of ten. 

We use it for running unit tests for merge requests on github. We also use it to build executable artifacts and also for running security scans.

Time to deployment has been reduced. It has helped in preventing us from deploying breaking changes into production. If the pipelines are configured properly and a merge request is created on the repository, the TeamCity pipeline triggers and highlights if there are breaking changes or failing unit tests. This has helped us reduce error rates immensely.

I find the TeamCity backend easily accessible. Users can login to the Linux servers that TeamCity is installed on and perform operations. Also I find the ability to template solutions using the meta runner a good feature as well as the user management feature. There is a display that shows which user made recent changes to a branch on GitHub, including the time the changes were made and the particular agent that ran the job. This is also a very useful feature. 

The metrics and audit available for projects, pipelines and  jobs come in handy when debugging.

The UI for this solution could be improved. New users don't find it easy to navigate. They need some level of training to understand the ins and the outs.

I have been using this solution for three years. 

It is a very stable solution. I prefer using it over Concourse. I have only experienced one scenario where a server had gone down due to configuration changes. Other than that, it has been stable and reliable. 

I would say it is highly scalable. Anyone in our business can easily setup their own TeamCity server and assign resources to it. We also have the ability to add multiple agents. In this respect, it is horizontally scalable. 

I have installed TeamCity for different teams with different needs for it. In some cases, we have needed docker containers to be installed with the setup as well as the Google Cloud SDK. With these additions, the setup can become complex. 

I would rate this solution a nine out of ten. 

We integrate TeamCity with Git for our development process. After the integration, we set up commands using web method integration to allow users to create builds and perform other tasks. These builds are then deployed on our internal servers.

We've found that TeamCity has significantly improved our deployment process by automating tasks that were previously done manually. This automation has reduced deployment time and increased efficiency for our team. 

One of the most beneficial features for us is the flexibility it offers in creating deployment steps tailored to different technologies. While we haven't used all of its capabilities extensively yet, we've found it easy to integrate with other solutions and flexible in handling various technologies. As for scalability, we've managed large-scale projects effectively by configuring different agents based on the project's scale and volume, which TeamCity supports well. Regarding stability and performance, while we haven't faced significant challenges, any issues we encounter are typically resolved by referring to the documentation, given our limited experience with TeamCity.

I haven't faced many challenges or issues that I would like to see improved in TeamCity. As for deployment challenges, they are often tied to the specific technology being integrated with TeamCity. In my case, integrating with certain technologies posed challenges related to time and required support from the respective technology teams to ensure smooth integration with TeamCity.

I have using TeamCity for the past 6 months. 

I don't have direct experience with maintenance or technical support for TeamCity as I'm not an administrator. My role primarily involves programming and user-level tasks. Therefore, I haven't escalated any questions to technical support.

The setup process was already done when I started working with it, so I didn't have much experience with that aspect. However, configuring the technology and integrating it was straightforward and easy to do. We are using the cloud version of TeamCity, and the experience has been smooth without major hurdles or complexities.

My overall rating for TeamCity is a 6, but I acknowledge that this rating is based on my limited experience with the tool. I haven't delved deeply into its functionalities or compared it extensively with other automation tools, which is why I consider it an average rating for now. 

We have different projects on TeamCity. Mainly, for example, I use it to automate our build. We have scripts that need to be run on schedule to do some scanning of our codes to detect vulnerabilities and so on. I have, for example, a build that decorates the script and launches it every Sunday night, so we can have our reports by Monday, so our managers can see them, and we can discuss them.

We also use it to deploy our infrastructure as code in the environment and to execute that or deploy that to the dev environment. We have many builds that deploy our code in the dev environment.

TeamCity is a very user-friendly tool. I didn't know about it five months ago, and I started digging into it. To be honest, it was very easy to start on it and to build my first build and to understand the concept or the methodology internally. 

It's very easy to configure as well. You can configure your build and the steps within in it in a very easy way since you can choose the syntax with how you will write your code. In comparison with Gitlab, Gitlab has its specific syntax, so you need to learn that; however, with TeamCity, you have the choice to choose the framework you want and so you can start easily. 

It's just a tool that I used. I needed to deliver something, so I did. I wasn't looking at it in a way to criticize it or to optimize it.

As a user, I need some more graphical design. For example, in the other CI/CD, the whole pipeline or the whole job, you can clearly see the different types. The first job, the second job, et cetera, and you can stop whenever you want. You can stop, for example, at the second job, and you can replace the second job, so you can continue where you have stopped.

However, in TeamCity, the whole build is like a whole block, and there is no way to stop. When the pipeline starts, there is no way that you can stop in the middle. You need to restart the whole thing. 

It's been five to six months, maybe, since I started using the solution.

The solution works quickly, and I haven't noticed any issues with stability; however, I haven't tried to test it out either. 

The whole IT department is using TeamCity. That's 40 to 50 people, approximately. Every dev and every DevOps person is using TeamCity.

I've never contacted technical support.

I'm also using GitLab.

It's easy to set up. I did it on my local machine, not on our real server, and it took me a couple of minutes. Since it's an online application, we can deploy it in just a minute and just with a few clicks. It's not that complicated.

It's open source, however, if you want your solution to be deployed on their cloud or on the cloud in general without you being involved and having it and managed by them, there may be costs involved. That's the paid feature.

I was not involved in evaluating other options or choosing this solution. 

I'm a customer and end-user.

We're using the latest version of the solution.

It's a great solution. I only wish they spent more time working on the graphical part. It would be nicer and more focused if they did.

I'd rate it seven out of ten as it is easy to start with, and it's not complicated to deploy in your on-premises deployment. 

We generally use TeamCity for automation and development.

TeamCity's GUI is nice.

One thing comes to mind, but maybe it's more of an issue on our side and not a problem with TeamCity itself. We don't have the high availability package. So I'd like our company to purchase that. So when one goes down, then we have a backup. I think we've purchased it, but we just haven't had anyone with the time to implement it. I think there was an extra cost, but we did buy it, and then I think you have to set it up in a certain way.

I've been using TeamCity for about three years. 

It's easy to scale, but this is on RDS, so you can scale it up and down. I don't think we purchased the scaling features, but they do have scalability. All of our developers are using it, so more than a hundred.

We've called TeamCity tech support. Unfortunately, all their tech support is based in Europe, so we end up with such a big time crunch that I now need to have one person in the US. Still, the tech support is pretty good. Even the original person that wrote the product is still working there, so that's good. But we have issues with the time zone.

It can be pretty complex. There's the RDS setup, where you use RDS, and you have agents and whatnot. I wouldn't say it's super complex. At the same time, it's not something where you just click a button, and you're done. It's kind of in the middle range. 

TeamCity is on the expensive side. It's more for developers than CIS admins. Conversely, Ansible is more for CIS admins and less for developers. It would be nice to have a solution that works for both purposes. So I think Ansible was something they were thinking about purchasing, but I'm not sure if that ever occurred.

There are two teams — on-prem and cloud — and the cloud team uses TeamCity. On-prem uses SUSE automation.

I rate TeamCity eight out of 10.

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