TeamCity Reviews

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.

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.