TeamCity Reviews

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.

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.