TeamCity vs. BuildMaster: Move Beyond Basic Builds and Continuous Integration

In my previous post, I discussed the difference between Jenkins and BuildMaster. As many folks found this interesting and informative, I've decided to do the same of TeamCity.

As I’m sure you can guess, comparing TeamCity to BuildMaster is also a faulty comparison, more along the line of comparing apples to oranges. While together they make a great fruit salad, or in our case; part of a DevOps toolchain, their individual functionality is quite different.

Continuous Integration vs Application Release Automation

This can really be boiled down to: Builds vs. Releases.

Fundamentally, Builds and Releases vary in two distinct ways: Builds meet developer or development needs, and Releases fulfill the IT organization requirements, and deliver end results. By separating tools into these unique, and separately functioning categories, you are able to address and solve the individual problem or requirement associated with each.

Although CI and ARA are two distinct separate processes, that address two distinct problems, some seek a single, multi-purpose tool to do it all. Obviously, no such tool exists. Just as a bike is no replacement for a car, TeamCity is simply not suitable for implementing a modern DevOps process.

Build Jobs as the Center of DevOps?

Like all Continuous Integration tools, TeamCity is focused on build automation. This is implemented primarily through Projects and Build Configurations, which define Build Steps: the source control, build, and other third-party tools used to checkout, compile, and test source code.

Of course, since a build step could just be an arbitrary script, a job could be used to do anything. And thus, TeamCity could be used for anything.

But just as an all-purpose Job Scheduler would be a poor choice for build automation jobs, TeamCity is an equally-poor choice for an all-purpose job scheduler. It lacks the features all other job schedulers have because it was never designed as a job scheduler.

Moreover, both job schedulers and build automation tools are poor choices for application release automation, and deployment.

Deployers are not for Deployment

One category of the built-in Build Steps in TeamCity is Deployers. Although the name implies that they might be used for application deployment, the intended usecase is much more limited: “Deployer build runners enable TeamCity to upload artifacts to external locations in a number of ways.”

There’s a lot more involved with deploying applications than uploading artifacts; not just additional automation tasks such as service stops/starts, but process orchestration, such as approval gates, manual intervention, security, and so on.

TeamCity with BuildMaster

Although TeamCity isn’t suitable for release coordination or enterprise deployment automation, it’s an established, and powerful build automation tool. This is exactly why BuildMaster has a tight integration with it; with the TeamCity extension, you can import build artifacts directly from TeamCity into BuildMaster, apply the necessary approvals, additional testing, and deploy to production. Together, and with other tools, BuildMaster and TeamCity help define and establish best practices for DevOps implementation.

Check out our tutorial on how to deploy a TeamCity Build with BuildMaster to learn how seamlessly the tools work together.