TeamCity Reviews

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.

• Centralized build automation
• Ability to embed powershell scripts for automated deployments
• Auditability of builds
• Unit tests
• Smoke tests
• Automated deployments

Continuous integration has reduced build failures and highlighted issues sooner. Automated deployments of web services, database scripts and applications chained across all environments has minimized time and effort, sped up delivery time, reduced risk of human error and enabled automated communication to stakeholders via integration with JIRA for release notes.

I've used it for three years.

Occasionally issues deploying software using the tool due to configuration issues within the tool (mostly around powershell configuration).

We had to add additional servers to enable a failover capability, but this was more to do with our infrastructure

No issues enquired.

I've not required customer service.

It's good. It's done via online forums.

We previously used Jenkins and Cruise control. We changed to enable one common solution and standard support model, also better functionality.

It was very simple. I have also installed on my home server to enable me to continue to develop and learn the tool.

We did it in-house.

The initial cost was only the cost of a virtual server, and database which was less than 1000 Euros a month. I am not aware of ongoing costs.

No other options were evaluated.

Make sure you define the standards and naming conventions prior to implementing TeamCity.

I spend less time scripting to get a build working and more time configuring TeamCity through its web-based front end.

It delegates the building of executable code to a machine.

More build runners and more options are needed, although I have no worries they keep improving.

This is the second job I have used it at. I have used other CI systems in the past, but I have been using TeamCity around two years.

Actually, I ran into a problem and I needed to do a fresh install. TeamCity stores its configuration data separate from where it installs. so this makes upgrades smoother, but makes it harder to start with a fresh slate. The problem was the data directory of the service account was rerouted because it was a 64 bit OS to SysWOW64.

No, it stays running and performs build regularly.

For our usage, it has scaled well to our needs.

10/10 - their service is very professional and prompt.

10/10 - their service is very professional and prompt, and their staff really wants to solve your problems.

I had used CruiseControl.NET in the past. It was useful once running, but painful to initially setup, and we used word of mouth and articles showing comparisons with other frameworks.

Just installing it with one agent is a breeze. The starting free license comes with three build agents, which, if you install them all as services, takes a little modifying of config files and running of batch files.

I implemented it.

Yet to be calculated. I am trying to automate the release of deliverables to free someone's time up.

Start with the free license it has decent room for one group.

Start small. Start with just doing builds before executing tests.

• General ease of use
• Quick start up time
• NUnit build runner

• Continuous deployment
• Continuous integration
• Testing feedback

I've used it for four years.

No issues encountered.

No issues encountered.

No issues encountered.

There was no previous solution in place.

It's straightforward as the UI is intuitive.

I implemented it myself.

It's free, so very good.

Start with the free version, and go from there.

No other options were evaluated.

Get someone who knows it well to go through the basics, but there's also loads of help on Google.

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