Bamboo vs TeamCity

Bamboo is the only build server to offer first-class support for the "delivery" aspect of continuous delivery. Deployment projects automate the tedium right out of releasing into each environment, while letting you control the flow with per-environment permissions.

When connecting Bamboo with Stash and JIRA, details like JIRA issues, commits, reviews and approvals follow each release from development to production. If HipCHat is part of the integration, team members get notified right away in addition to email notifications.

Bamboo allows using Docker containers to create build agents. Using Docker agents lets you run multiple remote agents on the same host without conflicting requirements. It makes it easier to duplicate and distribute changes to build agents, and to use scripts for creating and maintaining agents.

How can you define and build your own image and push it to a registry to share? This is when Bamboo’s Docker tasks come into play. Docker tasks make it possible to build an image, run a container, and push a Docker image to a registry from within your build or deployment project.

Bamboo allows you to automatically detect and build new branches, merge branches together when tests pass and continuously deploy code to staging and production servers based on branch name.

Out-of-the-box features that let developers perform parallel testing on elastic agents and quarantine flakey tests.

Avoid plugin hell by having most important capabilities as out-of-the-box features, not plugins. Bamboo is not just built for teams, but teams-of-teams. It has the administrative features you need to manage and maintain CI at scale. Enterprise model for access control, management, and support.

Deploying applications with AWS CodeDeploy was always possible by using Bamboo script tasks, and it's now an easier process with a bundled add-on and its accompanying CodeDeploy task.

Bamboo can also be integrated with Amazon S3 for unlimited storage.

TeamCity has different installation packages for different operating systems. All the user needs to do is download the correct one and run it.

The fact that it is based on Java does not hinder TeamCity's ability to support different build environments. TeamCity in fact supports a large number of languages and tools for each of those languages (build runners and test frameworks).

Some of the languages/platforms that are supported include: Ruby, .NET, Java.

The user interface of TeamCity is clear, well thought out and the dashboard is highly customizable.

The user can easily compose dependencies between builds by adding snapshot and artifact dependencies, all on the one screen. All output of upstream builds is available to downstream builds. Triggering sets off the entire build chain and supports re-running of the portions of the chain that failed.

TeamCity offers well defined APIs for extending, as well as a REST interface.

TeamCity supports both MSTest and NUnit (which is open source) to run tests.

Seems to be the best choice for .NET applications, but to be honest: if you stray from the default settings you will be in a lot of pain most of the time.